Docs Menu
Docs Home
/

Migrar un clúster fragmentado autogestionado a un hardware diferente

Este tutorial es específico para MongoDB 8.0. Para versiones anteriores de MongoDB, consulte la versión correspondiente del Manual de MongoDB.

Los servidores de configuración para clústeres fragmentados se implementan como un Conjunto de réplicas. Los servidores de configuración del conjunto de réplicas deben ejecutar el motor de almacenamiento WiredTiger.

Este procedimiento mueve los componentes del clúster fragmentado a un nuevo sistema de hardware sin tiempo de inactividad para lecturas y escrituras.

Importante

Mientras la migración esté en curso, no intente cambiar los metadatos del clúster fragmentado. No utilice ninguna operación que modifique los metadatos del clúster. Por ejemplo, no cree ni elimine bases de datos, colecciones ni utilice comandos de fragmentación.

A partir de MongoDB 8.0, puedes usar el directShardOperations Función para realizar operaciones de mantenimiento que requieren ejecutar comandos directamente contra un fragmento.

Advertencia

Ejecutar comandos usando el rol de directShardOperations puede hacer que su clúster deje de funcionar correctamente y puede causar corrupción de datos. Utilice el rol de directShardOperations solo para fines de mantenimiento o bajo la orientación del soporte de MongoDB. Una vez que haya terminado de realizar las operaciones de mantenimiento, deje de usar el rol de directShardOperations.

Desactive el balanceador para detener la migración de fragmentos y no realizar ninguna operación de escritura de metadatos hasta que finalice el proceso. Si hay una migración en curso, el balanceador la completará antes de detenerse.

Para deshabilitar el balanceador, conéctese a una de las instancias del clúster y emita el siguiente mongos método: []1

sh.stopBalancer()

Para comprobar el estado del equilibrador, emita el sh.getBalancerState() método.

Para obtener más información,consulte Deshabilitar el balanceador.

[1] A partir de MongoDB,6.0.3 no se realiza la división automática de fragmentos. Esto se debe a mejoras en la política de balanceo. Los comandos de división automática aún existen, pero no realizan ninguna operación. En versiones de MongoDB anteriores 6.0.3 a, sh.stopBalancer() también deshabilita la división automática para el clúster fragmentado.

Los servidores de configuración para clústeres fragmentados se pueden implementar como un conjunto de réplicas (CSRS). El uso de un conjunto de réplicas para los servidores de configuración mejora la consistencia entre ellos, ya que MongoDB puede aprovechar los protocolos estándar de lectura y escritura de conjuntos de réplicas para los datos de configuración. Además, el uso de un conjunto de réplicas para servidores de configuración permite que un clúster fragmentado tenga más de 3 servidores de configuración, ya que un conjunto de réplicas puede tener hasta 50 miembros. Para implementar servidores de configuración como un conjunto de réplicas, estos deben ejecutar el motor de almacenamiento WiredTiger.

Las siguientes restricciones se aplican a una configuración de conjunto de réplicas cuando se utiliza para servidores de configuración:

  • Debe tener cero árbitros.

  • No debe tener miembros retrasados.

  • Se deben crear índices (es decir, ningún miembro debe tener la configuración establecida en members[n].buildIndexes falso).

Para cada miembro del conjunto de réplicas del servidor de configuración:

Importante

Reemplace los miembros secundarios antes de reemplazar los primarios.

1

Inicie una instancia, especificando mongod las --configsvr --replSetopciones,, --bind_ip y otras opciones según corresponda a su implementación.

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 --configsvr --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>
2

Conectar mongosh al servidor principal del conjunto de réplicas de configuración y use rs.add() para agregar el nuevo miembro.

Advertencia

Antes de MongoDB,5.0 un miembro secundario recién añadido seguía contando como miembro con derecho a voto, aunque no pudiera realizar lecturas ni convertirse en miembro principal hasta que sus datos fueran consistentes. Si ejecuta una versión de MongoDB anterior a 5.0 y añade un miembro secundario votes con sus valores y priority mayores que cero, esto puede provocar que la mayoría de los miembros con derecho a voto estén conectados, pero no se pueda elegir ningún miembro principal. Para evitar estas situaciones, considere añadir el nuevo miembro secundario inicialmente con priority :0 votes :0y. A continuación, ejecute rs.status() para asegurarse de que el miembro haya pasado al SECONDARY estado. Finalmente, utilice rs.reconfig() para actualizar su prioridad y votos.

rs.add( { host: "<hostnameNew>:<portNew>", priority: 0, votes: 0 } )

El proceso de sincronización inicial copia todos los datos de un miembro del conjunto de réplicas del servidor de configuración al nuevo miembro sin reiniciar.

mongos Las instancias reconocen automáticamente el cambio en los miembros del conjunto de réplicas del servidor de configuración sin reiniciar.

3
  1. Asegúrese de que el nuevo miembro haya alcanzado el estado. Para comprobar el estado de los miembros del conjunto de SECONDARY réplicas,rs.status() ejecute:

    rs.status()
  2. Reconfigurar el conjunto de réplicas para actualizar los votos y la prioridad del nuevo miembro:

    var cfg = rs.conf();
    cfg.members[n].priority = 1; // Substitute the correct array index for the new member
    cfg.members[n].votes = 1; // Substitute the correct array index for the new member
    rs.reconfig(cfg)

    donde n es el índice de la matriz del nuevo miembro en la matriz.members

Advertencia

  • El rs.reconfig() método de shell puede forzar la desconexión del servidor principal actual, lo que provoca una elección. Cuando la desconexión del servidor principal se produce, el mongod método cierra todas las conexiones de cliente. Aunque esto suele tardar 10entre y20 segundos, intente realizar estos cambios durante los periodos de mantenimiento programados.

  • Evitar reconfigurar sets de réplicas que contengan miembros de diferentes versiones de MongoDB, ya que las reglas de validación pueden diferir entre versiones de MongoDB.

4

Si reemplaza el miembro principal, baje primero el primario antes de apagarlo.

5

Una vez completada la sincronización inicial del servidor de configuración de reemplazo, desde una sesión que esté mongosh rs.remove() conectada al servidor principal, use para eliminar el miembro antiguo.

rs.remove("<hostnameOld>:<portOld>")

mongos Las instancias reconocen automáticamente el cambio en los miembros del conjunto de réplicas del servidor de configuración sin reiniciar.

Con servidores de configuración de conjuntos de mongos réplicas, las instancias especifican en la --configdb sharding.configDB configuración u el nombre del conjunto de réplicas del servidor de configuración y al menos uno de sus miembros. Las mongos instancias del clúster fragmentado deben especificar el mismo nombre del conjunto de réplicas del servidor de configuración, pero pueden especificar diferentes miembros.

Si una instanciamongosespecifica un miembro del conjunto de réplicas migrado en la configuración--configdbosharding.configDB, actualice la configuración del servidor para la próxima vez que reinicie la instanciamongos.

Para obtener más información, consulte Iniciar un mongos para el clúster fragmentado.

Migre los fragmentos uno a uno. Para cada fragmento, siga el procedimiento correspondiente de esta sección.

Para migrar un clúster fragmentado, migre cada miembro por separado. Primero migre los miembros no principales y, por último, el principal.

Si el conjunto de réplicas tiene dos miembros con derecho a voto, agréguele un árbitro para garantizar que mantenga la mayoría de sus votos disponibles durante la migración. Puede eliminar al árbitro una vez completada la migración.

  1. Cierre el proceso. Para asegurar mongod shutdown un cierre limpio, use el comando.

  2. Mueva el directorio de datos (es decir,) a la nueva dbPath máquina.

  3. Reinicie el proceso en la nueva mongod ubicación.

  4. Conéctese al servidor principal actual del conjunto de réplicas.

  5. Si el nombre de host del miembro ha cambiado, utilice rs.reconfig() para actualizar el documento de configuración del conjunto de réplicas con el nuevo nombre de host.

    Por ejemplo, la siguiente secuencia de comandos actualiza el nombre de host de la instancia en la posición 2 en la matriz members:

    cfg = rs.conf()
    cfg.members[2].host = "pocatello.example.net:27018"
    rs.reconfig(cfg)

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

  6. Para confirmar la nueva configuración,rs.conf() emita.

  7. Espere a que el miembro se recupere. Para comprobar su estado,rs.status() ejecute.

Al migrar el conjunto de réplicas principal, este debe elegir un nuevo conjunto. Este proceso de conmutación por error impide que el conjunto de réplicas pueda realizar lecturas o aceptar escrituras durante la elección, que suele completarse rápidamente. Si es posible, planifique la migración durante una ventana de mantenimiento.

  1. Reducir la carga del servidor principal para permitir el proceso normal de conmutación por error. Para reducir la carga del servidor principal, conéctese a él y ejecute replSetStepDown el comando o el rs.stepDown() método. El siguiente ejemplo muestra el rs.stepDown() método:

    rs.stepDown()
  2. Una vez que el servidor principal se ha reducido y otro miembro ha alcanzado el PRIMARY estado, para migrar el servidor principal reducido, siga el procedimiento "Migrar un miembro de un fragmento de conjunto de réplicas".

    Puede comprobar la salida de rs.status() para confirmar el cambio de estado.

Para completar la migración, vuelva a habilitar el balanceador para reanudar las migraciones de fragmentos.

Conéctese a una de las instancias del clúster y mongos pase true al sh.startBalancer() método: []2

sh.startBalancer()

Para comprobar el estado del equilibrador, emita el sh.getBalancerState() método.

Para obtener más información, consulte Habilitar el balanceador.

[2] A partir de MongoDB,6.0.3 la división automática de fragmentos no se realiza. Esto se debe a mejoras en la política de balanceo. Los comandos de división automática aún existen, pero no realizan ninguna operación. En versiones de MongoDB anteriores 6.0.3 a, sh.startBalancer() también habilita la división automática para el clúster fragmentado.

Volver

Reiniciar un clúster fragmentado

En esta página