El tutorial está orientado específicamente a MongoDB 6.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 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 a un nuevo sistema de hardware sin interrupciones para lecturas y guardados.
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.
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 Deshabilitar el balanceador.
| [1] | A partir de MongoDB 6.0.3, no se realiza la partición automática de fragmentos. Esto se debe a mejoras en las políticas de equilibrio. Los comandos de división automática siguen existiendo, pero no realizan una operación. Para más información, consulta Cambios en la política de balanceo.En versiones de MongoDB anteriores a la 6.0.3, 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.
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.
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.
Inicie 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 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.
Actualizar la configuración de votos y prioridad del nuevo servidor de configuración agregado.
Asegúrese de que el nuevo miembro haya alcanzado el estado. Para comprobar el estado de los miembros del conjunto de
SECONDARYréplicas,rs.status()ejecute: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 conjunto de réplicas del servidor de configuración sin 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 un fragmento de conjunto de réplicas
Para migrar un clúster fragmentado, migre cada miembro por separado. Primero migre los miembros no principales y, por último, el principal.
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éctese al servidor principal actual del conjunto 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
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.
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
replSetStepDownel comando o elrs.stepDown()método. El siguiente ejemplo muestra elrs.stepDown()método: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.
Volver 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 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 siguen existiendo, pero no realizan ninguna operación. Para obtener más información, consulte Cambios en la política de balanceo.En versiones de MongoDB anteriores a la 6.0.3, sh.startBalancer() también habilita la división automática para el clúster fragmentado. |