Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

Cambia los nombres de host en un set de réplicas autogestionado

Para la mayoría sets de réplicas, los nombres de host en el members[n].host campo nunca cambia. Sin embargo, si las necesidades de la organización cambian, puede que sea necesario migrar algunos o todos los nombres de host.

Nota

Siempre utiliza nombres de host resolubles para el valor del campo members[n].host en la configuración del set de réplicas para evitar confusiones y complejidad.

Importante

Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.

Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.

Este documento proporciona dos procedimientos separados para cambiar los nombres de host en el campo members[n].host. Utiliza cualquiera de los siguientes enfoques:

  • Cambie los nombres de host sin interrumpir la disponibilidad. Este enfoque garantiza que tus aplicaciones siempre puedan leer y guardar datos en el set de réplicas, pero el proceso puede llevar mucho tiempo y podría ocasionar tiempo de inactividad en la capa de la aplicación.

    Si utiliza el primer procedimiento, debe configurar sus aplicaciones para conectarse al set de réplicas tanto en la ubicación antigua como en la nueva, lo que a menudo requiere un reinicio y una reconfiguración en la capa de la aplicación, y lo que puede afectar la disponibilidad de sus aplicaciones. Reconfigurar aplicaciones está fuera del alcance de este documento.

  • Detener todos los miembros que se ejecutan en los antiguos hostnames a la vez. Este enfoque tiene un periodo de mantenimiento más corto, pero el set de réplicas estará indisponible durante la operación.

Tip

Dado un set de réplicas con tres miembros:

  • database0.example.com:27017 (the primario/a)

  • database1.example.com:27017

  • database2.example.com:27017

Y con la siguiente rs.conf() salida:

{
"_id" : "rs",
"version" : 3,
"members" : [
{
"_id" : 0,
"host" : "database0.example.com:27017"
},
{
"_id" : 1,
"host" : "database1.example.com:27017"
},
{
"_id" : 2,
"host" : "database2.example.com:27017"
}
]
}

Los siguientes procedimientos modifican los nombres de host de los nodos de la siguiente manera:

  • mongodb0.example.net:27017 (el principal)

  • mongodb1.example.net:27017

  • mongodb2.example.net:27017

Utiliza el procedimiento más adecuado para tu implementación.

Este procedimiento utiliza las suposiciones anteriores.

  1. Para cada secundario en el set de réplicas, realiza la siguiente secuencia de operaciones:

    1. Detener la secundaria.

    2. Reiniciar el secundario en la nueva ubicación.

    3. Conectar mongosh al primario del set de réplicas. En nuestro ejemplo, la principal se ejecuta en el puerto 27017, así que se emitiría el siguiente comando:

      mongosh --port 27017
    4. Utiliza rs.reconfig() para actualizar el documento de configuración de set de réplicas con el nuevo nombre de host.

      Por ejemplo, la siguiente secuencia de comandos actualiza el nombre de host para el secundario en el índice del arreglo 1 del arreglo members (es decir, members[1]) en el documento de configuración del set de réplicas:

      cfg = rs.conf()
      cfg.members[1].host = "mongodb1.example.net:27017"
      rs.reconfig(cfg)

      Para obtener más información sobre cómo actualizar el documento de configuración, consulta Ejemplos.

    5. Asegúrate de que tus aplicaciones cliente puedan acceder al conjunto en la nueva ubicación y de que el secundario tenga la oportunidad de ponerse al día con los demás miembros del conjunto.

      Repite los pasos anteriores para cada miembro no principal del conjunto.

  2. Conectar mongosh al primario y reducir el primario utilizando el método rs.stepDown():

    rs.stepDown()

    El set de réplicas elige otro nodo para que se convierta en primario.

  3. Cuando la degradación tenga éxito, apague el primario antiguo.

  4. Inicia la instancia mongod que se convertirá en la nueva principal en la nueva ubicación.

  5. Conéctese al primario actual, que acaba de ser elegido, y actualice el documento de configuración del set de réplicas con el nombre de host del nodo que se convertirá en el nuevo primario.

    Por ejemplo, si la anterior base de datos principal estaba en la posición 0 y el nuevo hostname de la base de datos principal es mongodb0.example.net:27017, se debe ejecutar:

    cfg = rs.conf()
    cfg.members[0].host = "mongodb0.example.net:27017"
    rs.reconfig(cfg)
  6. Conecta mongosh con el nuevo primario.

  7. Para confirmar la nueva configuración, llama a rs.conf() en mongosh.

    Su resultado debe parecerse a:

    {
    "_id" : "rs",
    "version" : 4,
    "members" : [
    {
    "_id" : 0,
    "host" : "mongodb0.example.net:27017"
    },
    {
    "_id" : 1,
    "host" : "mongodb1.example.net:27017"
    },
    {
    "_id" : 2,
    "host" : "mongodb2.example.net:27017"
    }
    ]
    }

Este procedimiento utiliza las suposiciones anteriores.

El siguiente procedimiento lee y actualiza la colección system.replset en la base de datos local.

Si tu implementación aplica control de acceso, el usuario que realiza el procedimiento debe tener acciones de privilegio de find y update en la colección system.replset.

Para crear un rol que proporcione los privilegios necesarios:

  1. Inicie sesión como un usuario con privilegios para gestionar usuarios y roles, como un usuario con el rol de userAdminAnyDatabase. El siguiente procedimiento utiliza el myUserAdmin creado en Habilitar el control de acceso en implementaciones autogestionadas.

    mongosh --port 27017 -u myUserAdmin --authenticationDatabase 'admin' -p
  2. Crea un rol de usuario que proporcione los privilegios necesarios sobre la colección system.replset en la base de datos local:

    db.adminCommand( {
    createRole: "systemreplsetRole",
    privileges: [
    { resource: { db: "local", collection: "system.replset" }, actions: ["find","update"] }
    ],
    roles: []
    } );
  3. Otorga el rol al usuario que va a realizar el procedimiento de cambio de nombre. Por ejemplo, lo siguiente asume un usuario existente "userPerformingRename" en la base de datos admin.

    use admin
    db.grantRolesToUser( "userPerformingRename", [ { role: "systemreplsetRole", db: "admin" } ] );
  1. Detener a todos los nodos en el set de réplicas.

  2. Reinicia cada nodo en un puerto diferente y sin usar la opción de tiempo de ejecución --replSet. Al cambiar el número de puerto durante el mantenimiento se impide que los clientes se conecten a este host mientras ejecuta el mantenimiento. Utiliza el --dbpath habitual del nodo, que en este ejemplo es /data/db1. Utiliza un comando que se asemeje al siguiente:

    Advertencia

    Antes de vincular la instancia a una dirección IP de acceso público, se debe asegurar el clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, se debe consultar Checklist de seguridad para implementaciones autogestionadas. Como mínimo, se debe considerar habilitar la autenticación y reforzar la infraestructura de red.

    mongod --dbpath /data/db1/ --port 37017 --bind_ip localhost,<hostname(s)|ip address(es)>

    Importante

    Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.

    Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.

  3. Para cada nodo del set de réplicas, realice la siguiente secuencia de operaciones:

    1. Conecta mongosh al mongod que se ejecuta en el nuevo y temporal puerto. Por ejemplo, para un nodo que se ejecuta en un puerto temporal de 37017, emitirías este comando:

      mongosh --port 37017

      Si se ejecuta con control de acceso, connectarse como usuario con privilegios adecuados. Ver Prerrequisitos.

      mongosh --port 37017 -u userPerformingRename --authenticationDatabase=admin -p
    2. Edita la configuración del set de réplicas manualmente. La configuración del set de réplicas es el único documento en la colección system.replset de la base de datos local.


      Para cambiar los nombres de host, edita la configuración del set de réplicas para proporcionar los nuevos nombres de host y puertos para todos los miembros del set de réplicas.

      1. Cambia a la base de datos local .

        use local
      2. Cree una variable de JavaScript para el documento de configuración. Modifica el valor del _id campo para que coincida con tu set de réplicas.

        cfg = db.system.replset.findOne( { "_id": "rs0" } )
      3. Proporciona nuevos nombres de host y puertos para cada nodo del set de réplicas. Modifica los nombres de host y los puertos para que coincidan con el set de réplicas.

        cfg.members[0].host = "mongodb0.example.net:27017"
        cfg.members[1].host = "mongodb1.example.net:27017"
        cfg.members[2].host = "mongodb2.example.net:27017"
      4. Actualiza los nombres de host y los puertos en la colección system.replset:

        db.system.replset.updateOne( { "_id": "rs0" }, { $set: cfg } )
      5. Verifica los cambios:

        db.system.replset.find( {}, { "members.host": 1 } )
    3. Detener el proceso mongod en el nodo.

  4. Después de reconfigurar todos los nodos del conjunto, inicie cada instancia de mongod de la manera normal: use el número de puerto habitual y la opción --replSet. Por ejemplo:

    Advertencia

    Antes de vincular la instancia a una dirección IP de acceso público, se debe asegurar el clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, se debe consultar Checklist de seguridad para implementaciones autogestionadas. Como mínimo, se debe considerar habilitar la autenticación y reforzar la infraestructura de red.

    mongod --dbpath /data/db1/ --port 27017 --replSet rs0 --bind_ip localhost,<hostname(s)|ip address(es)>
  5. Conéctate a una de las instancias de mongod usando mongosh. Por ejemplo:

    mongosh --port 27017
  6. Para confirmar la nueva configuración, llama a rs.conf() en mongosh.

    Su resultado debe parecerse a:

    {
    "_id" : "rs0",
    "version" : 4,
    "members" : [
    {
    "_id" : 0,
    "host" : "mongodb0.example.net:27017"
    },
    {
    "_id" : 1,
    "host" : "mongodb1.example.net:27017"
    },
    {
    "_id" : 2,
    "host" : "mongodb2.example.net:27017"
    }
    ]
    }

Volver

Gestionar la replicación en cadena

En esta página