El tutorial es específico para MongoDB 5.0. Para versiones anteriores de MongoDB, consulta la versión correspondiente del Manual de MongoDB.
Los servidores de configuración para clústeres particionados se implementan como un set de réplicas. Los servidores de configuración del set de réplicas deben ejecutar el motor de almacenamiento WiredTiger.
Este procedimiento mueve los componentes del clúster a un nuevo sistema de hardware sin interrupciones para lecturas y guardados.
Importante
Mientras se realiza la migración, no intente cambiar a los Metadatos de clúster fragmentado. No utilice ninguna operación que modifique los metadatos del clúster de ninguna manera. Por ejemplo, no crees ni elimines bases de datos, no crees ni elimines colecciones, ni utilices ningún comando de particionamiento.
Desactivar el balanceador
Deshabilitar el balanceador para detener la migración de fragmentos y no realizar ninguna operación de escritura de metadatos hasta que el proceso termine. Si una migración está en curso, el balanceador completará la migración en curso antes de detenerse.
Para deshabilitar el balanceador, conéctese a uno de los clústeres
mongos instancias y emita el siguiente método: [1]
sh.stopBalancer()
Para comprobar el estado del balanceador, emite el método sh.getBalancerState().
Para obtener más información, consulte Desactiva el balanceador.
| [1] | A partir de MongoDB 4.2, sh.stopBalancer() también desactiva la división automática para el clúster fragmentado. |
Migrar cada servidor de configuración por separado
Los servidores de configuración para clústeres sharded pueden implementarse como un set de réplicas (CSRS). Utilizar un set de réplicas para los servidores de configuración mejora la coherencia entre los servidores de configuración, ya que MongoDB puede aprovechar los protocolos estándar de lectura y escritura de sets de réplicas para los datos de configuración. Además, el uso de un set de réplicas para los servidores de configuración permite que un cluster shard tenga más de 3 servidores de configuración, ya que un set de réplicas puede tener hasta 50 miembros. Para implementar servidores de configuración como un set de réplicas, los servidores de configuración deben ejecutar el Motor de almacenamiento WiredTiger.
Se aplican las siguientes restricciones a una configuración de set de réplicas cuando se utilizan para servidores de configuración:
Debe tener cero árbitros.
No debe tener miembros atrasados.
Deben crear índices (i.e. ningún nodo debería tener el ajuste
members[n].buildIndexesajustado en falso).
Para cada nodo del set de réplicas del servidor de configuración:
Importante
Reemplace los miembros secundarios antes de reemplazar los primarios.
Inicia el servidor de configuración de reemplazo.
Inicie una instancia de mongod, especificando las opciones --configsvr, --replSet, --bind_ip y otras opciones según corresponda a su implementación.
Advertencia
Antes de enlazar a un host que no sea localhost (por ejemplo, Públicamente accesible) dirección IP, asegúrese de que ha protegido su clúster de accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulta la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considera activar la autenticación y fortalecer la infraestructura de red.
mongod --configsvr --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>
Agregue el nuevo servidor de configuración al set de réplicas.
Conecta mongosh al primario del set de réplicas de servidores de configuración y utiliza rs.add() para agregar el nuevo nodo.
Advertencia
Antes de MongoDB 5.0, un nuevo secundario añadido aún cuenta como nodo con derecho a voto incluso aunque no pueda servir lecturas ni convertirse en primario hasta que sus datos sean coherentes. Si tienes una versión de MongoDB anterior a la 5.0 y agregas un secundario con su votes y la configuración de priority mayor a cero, esto puede llevar a una situación en la que la mayoría de los nodos con derecho a voto estén en linea pero no se pueda elegir un primario. Para evitar estas situaciones, considera añadir el nuevo arrendatario secundario, inicialmente, con priority :0 y votes :0. Después, ejecuta rs.status() para asegurar que el nodo haya pasado al estado SECONDARY. Por último, usa 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 nodo del set de réplicas del servidor de configuración al nuevo nodo sin reiniciar.
mongos las instancias reconocen automáticamente el cambio en los miembros del set de réplicas del servidor de configuración sin necesidad de reiniciar.
Actualizar la configuración de votos y prioridad del nuevo servidor de configuración agregado.
Asegúrese de que el nuevo nodo haya alcanzado el estado de
SECONDARY. Para verificar el estado de los miembros del set de réplicas, ejecutars.status():rs.status() Reconfigura el set de réplicas para actualizar los votos y la prioridad del nuevo nodo:
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
nes el índice del nuevo nodo en el arreglomembers.
Advertencia
El método de shell
rs.reconfig()puede forzar el traspaso del primario actual, lo que provoca una elección. Cuando el primario renuncia, elmongodcierra todas las conexiones de los clientes. Aunque esto generalmente toma entre 10 y 20 segundos, intente hacer 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.
Remueve el miembro a reemplazar del set de réplicas del servidor de configuración.
Al completar la sincronización inicial del servidor de configuración de reemplazo, desde una sesión mongosh conectada al primario, utiliza rs.remove() para remover el nodo antiguo.
rs.remove("<hostnameOld>:<portOld>")
mongos las instancias reconocen automáticamente el cambio en los miembros del set de réplicas del servidor de configuración sin necesidad de reiniciar.
Reiniciar las instancias mongos
Con los servidores de configuración del set de réplicas, las instancias de mongos especifican en la configuración --configdb o sharding.configDB el nombre del set de réplicas del servidor de configuración y al menos uno de los miembros del set de réplicas. Las mongos instancias para el clúster deben especificar el mismo nombre del set de réplicas del servidor de configuración, pero pueden especificar diferentes nodos del set de réplicas.
Si una instancia de mongos especifica un miembro de set de réplicas migrado en la configuración --configdb o sharding.configDB, actualice la configuración del servidor de configuración para la próxima vez que reinicie la instancia mongos.
Para obtener más información, consulte Iniciar un mongos para el clúster fragmentado.
Migrar las particiones
Migra las particiones una a la vez. Para cada partición, debe seguir el procedimiento correspondiente indicado en esta sección.
Migrar una partición del set de réplicas
Para migrar un clúster fragmentado, migra cada nodo por separado. Primero migrar los miembros no principales y luego migrar el principal al final.
Si el set de réplicas tiene dos miembros con derecho a voto, agregue un árbitro al set de réplicas para asegurar que el set mantenga la mayoría de sus votos disponibles durante la migración. Puede remover el árbitro después de completar la migración.
Migrar un nodo de un set de réplicas de partición
Apague el proceso
mongod. Para garantizar un cierre limpio, utilice el comandoshutdown.Mueve el directorio de datos (es decir, el
dbPath) a la nueva máquina.Reinicia el proceso
mongoden la nueva ubicación.Conéctate al primario actual del set de réplicas.
Si el nombre de host del nodo ha cambiado, utiliza
rs.reconfig()para actualizar el documento de configuración del set 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
2en el arreglomembers: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, consulta Ejemplos.
Para confirmar la nueva configuración, emite
rs.conf().Espera a que se recupere el nodo. Para verificar el estado del nodo, emite
rs.status().
Migra el primario en una partición de set de réplicas
Durante la migración del primario del set de réplicas, el set debe elegir un nuevo primario. Este proceso de conmutación por error hace que el set de réplicas no esté disponible para realizar lecturas o aceptar escrituras durante el tiempo que dura la elección, que normalmente se completa rápidamente. Si es posible, planifica la migración durante un periodo de mantenimiento.
Degrada el primario para permitir el proceso normal de failover. Para bajar el nivel del nodo principal, conecte con el nodo principal y ejecute el comando
replSetStepDowno el métodors.stepDown(). El siguiente ejemplo muestra el métodors.stepDown():rs.stepDown() Una vez que el primario haya renunciado y otro nodo haya pasado al estado
PRIMARY. Para migrar el primario degradado, sigue el procedimiento de Migrar un miembro de un set de réplicas particiónPuedes verificar la salida de
rs.status()para confirmar el cambio de estado.
Vuelva a habilitar el balanceador
Para completar la migración, vuelva a activar el equilibrador para reanudar las migraciones de fragmentos.
Conéctate a una de las instancias mongos del clúster y pasa true al método sh.startBalancer(): [2]
sh.startBalancer()
Para comprobar el estado del balanceador, emite el método sh.getBalancerState().
Para obtener más información, consulte Habilitar el balanceador.
| [2] | A partir de MongoDB 4.2, sh.startBalancer() también permite la división automática para el clúster fragmentado. |