Este tutorial es específico para MongoDB 7.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.
Desactivar el balanceador
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 uno de los clústeres
mongosinstancias y emite el siguiente 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. |
Migrar cada servidor de configuración por separado
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].buildIndexesfalso).
Para cada miembro del conjunto 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, 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)>
Agregue el nuevo servidor de configuración al set de réplicas.
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.
Actualice los votos y la configuración de prioridad del servidor de configuración recié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() 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
nes 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, elmongodmé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.
Eliminar el miembro a reemplazar del conjunto de réplicas del servidor de configuración.
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.
Reiniciar las mongos instancias
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.
Migrar los fragmentos
Migre los fragmentos uno a uno. Para cada fragmento, siga el procedimiento correspondiente de 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 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.
Migrar un miembro de un fragmento de conjunto de réplicas
Cierre el proceso. Para asegurar
mongodshutdownun cierre limpio, use el comando.Mueva el directorio de datos (es decir,) a la nueva
dbPathmáquina.Reinicie el proceso en la nueva
mongodubicación.Conéctese al servidor principal actual del conjunto de réplicas.
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
2en la matrizmembers: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.
Para confirmar la nueva configuración,
rs.conf()emita.Espere a que el miembro se recupere. Para comprobar su estado,
rs.status()ejecute.
Migrar el fragmento principal en un conjunto 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 servidor principal se ha reducido y otro miembro ha alcanzado el
PRIMARYestado, 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.
Volver a habilitar el balanceador
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. |