Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /
Actualizar de 5.0 a 6.0
Docs Home
/ /
6.0
/
Actualizar de 5.0 a 6.0
Docs Home
/
Manual de base de datos
/
Notas de versión
/
6.0
/
Actualizar de 5.0 a 6.0

Actualizar un clúster particionado a la versión 6.0

Advertencia

Debido a actualización de la política de equilibrio en MongoDB 6.0.3, el equilibrador puede comenzar inmediatamente después de la actualización, incluso si la cantidad de fragmentos sigue siendo la misma.

Familiarízate con el contenido de este documento, incluyendo una revisión exhaustiva de los requisitos previos, antes de actualizar a MongoDB 6.0.

Los siguientes pasos describen el procedimiento para actualizar un mongod que es un nodo de partición desde la versión 5.0 hasta la 6.0.

Si se necesita orientación sobre cómo actualizar a 6.0, los servicios profesionales de MongoDB ofrecen soporte para la actualización de versiones principales para ayudar a garantizar una transición sin problemas y sin interrupciones en la aplicación MongoDB.

Recomendaciones de actualizaciones y listas de verificación

Al actualizar, considere lo siguiente:

Ruta de actualización de versión

Para actualizar una implementación existente de MongoDB a 6.0, debes estar ejecutando una versión de la serie 5.0.

Para actualizar desde una versión anterior a la serie 5.0, debe actualizar sucesivamente las versiones principales hasta que se haya actualizado a la serie 5.0. Por ejemplo, si está ejecutando una serie 4.4, debe actualizar primero a 5.0 antes de poder actualizar a 6.0.

Verifique la compatibilidad del controlador

Antes de actualizar MongoDB, se debe comprobar que se está usando un driver compatible con MongoDB 6.0. Se debe consultar la documentación del driver para el driver específico que se está usando y verificar la compatibilidad con MongoDB 6.0.

Las implementaciones actualizadas que se ejecutan en controladores incompatibles podrían experimentar un comportamiento inesperado o indefinido.

Advertencia

Si tus drivers utilizan opcodes heredados que quedaron obsoletos en la versión 3.6, actualiza tus drivers a una versión que utilice opcodes admitidos. Los controladores que usen códigos de operación heredados ya no son compatibles.

Preparación

Antes de comenzar tu actualización, consulta el documento Cambios de compatibilidad en MongoDB 6.0 para asegurarte de que tus aplicaciones y implementaciones sean compatibles con MongoDB 6.0. Resuelve las incompatibilidades en tu implementación antes de comenzar la actualización.

Antes de actualizar MongoDB, siempre se debe probar la aplicación en un entorno de pruebas antes de implementar la actualización en el entorno de producción.

Consideración de reducción de versión

Después de actualizar a 6.0, si necesitas bajar de versión, te recomendamos regresar a la última versión menor de la versión 5.0.

Requisitos previos

Versión de todos los nodos

Para actualizar un clúster fragmentado a 6.0, todos los nodos del clúster deben tener al menos la versión 5.0. El proceso de actualización revisa todos los componentes del clúster y generará advertencias si algún componente ejecuta una versión anterior a 5.0.

Compatibilidad de características entre versiones

El clúster particionado 5.0 debe tener featureCompatibilityVersion configurado en "5.0".

Para garantizar que todos los nodos del clúster tengan featureCompatibilityVersion configurado en "5.0", conéctese a cada set de réplicas de la partición y a cada set de réplicas del servidor de configuración y verifique el featureCompatibilityVersion:

Tip

Para un clúster que tiene el control de acceso habilitado, para ejecutar el siguiente comando contra un miembro del set de réplicas, debes conectarte al miembro como un usuario local del shard.

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

Todos los nodos deben devolver un resultado que incluya "featureCompatibilityVersion" : { "version" : "5.0" }.

Para establecer o actualizar featureCompatibilityVersion, ejecute el siguiente comando en mongos:

db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } )

Para obtener más información, consulta setFeatureCompatibilityVersion.

Estado del nodo del set de réplicas

Para particiones y servidores de configuración, asegúrese de que ningún miembro del set de réplicas esté en el estado de ROLLBACK o RECOVERING.

Realiza una copia de seguridad de la base de datos config

Opcional, pero se recomienda. Como precaución, haz una copia de seguridad de la base de datos config antes de actualizar el clúster particionado.

Descargar binarios 6.0

Usar el gestor de paquetes

Si instaló MongoDB desde los repositorios de MongoDB apt, yum, dnf, o zypper, debe actualizar a 6.0 usando su gestor de paquetes.

Se deben seguir las instrucciones de instalación 6.0 adecuadas para su sistema Linux. Esto implicará añadir un repositorio para la nueva versión y, a continuación, realizar el proceso de actualización propiamente dicho.

Descarga 6.0 Binarios manualmente

Si no se ha instalado MongoDB usando un administrador de paquetes, se pueden descargar manualmente los binarios de MongoDB desde el Centro de Descargas de MongoDB.

Consulta Instrucciones de instalación 6.0 para obtener más información.

Procedimiento de actualización

Advertencia

Si actualizas una instancia existente de MongoDB a la versión 6.0.5, esa instancia puede fallar al arrancar si fork: true está configurado en el archivo mongod.conf.

El problema de actualización afecta a todas las instancias de MongoDB que utilizan los paquetes de instalación .deb o .rpm. Las instalaciones que utilizan la versión en tarball (.tgz) o de otros tipos de paquetes no se ven afectadas. Para obtener más información, consulte SERVIDOR-74345.

Para remover la configuración de fork: true, ejecute estos comandos desde una terminal del sistema:

systemctl stop mongod.service
sed -i.bak '/fork: true/d' /etc/mongod.conf
systemctl start mongod.service

El segundo comando systemctl inicia la instancia actualizada después de que se elimine la configuración.

1

Desactivar el balanceador.

Conecte mongosh a una instancia mongos en el clúster fragmentado y ejecute sh.stopBalancer() para desactivar el balanceador:

sh.stopBalancer()

Nota

Si una migración está en progreso, el sistema completará la migración en curso antes de detener el balanceador. Puedes ejecutar sh.isBalancerRunning() para comprobar el estado actual del balanceador.

Para comprobar que el balanceador esté deshabilitado, ejecuta sh.getBalancerState(), que retorna false si el balanceador está deshabilitado:

sh.getBalancerState()

Para obtener más información sobre cómo deshabilitar el balanceador, consulta Deshabilitar el balanceador.

2

Reinicia cada mongos secuencialmente.

  1. Ejecuta db.shutdownServer() para detener una instancia de mongos.

    db.shutdownServer()

  2. Reinicia la instancia mongos.

  3. Repita para cada instancia de mongos en el clúster.

3

Actualiza los servidores de configuración.

  1. Actualiza los miembros secundarios del set de réplicas, uno a la vez.

    1. Apague la instancia secundaria.

      Para cerrar el proceso mongod, use mongosh para conectarse al nodo del clúster y ejecutar el siguiente comando:

      db.adminCommand( { shutdown: 1 } )

    2. Reemplace el binario 5.0 con el binario 6.0.

    3. Inicie el binario 6.0.

      Inicia el binario 6.0 con el --configsvr, --replSet y --port. Incluya cualquier otra opción utilizada por la implementación.

      mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      Si usas un archivo de configuración, actualiza el archivo para especificar sharding.clusterRole: configsvr, replication.replSetName, net.port y net.bindIp; luego, inicia el binario 6.0:

      sharding:
         clusterRole: configsvr
      replication:
         replSetName: <string>
      net:
         port: <port>
         bindIp: localhost,<ip address>
      storage:
         dbpath: <path>

      Incluye cualquier otro ajuste que corresponda a tu implementación.

    4. Espere a que el nodo se recupere al estado SECONDARY antes de actualizar el siguiente nodo secundario.

      Para comprobar el estado del nodo, ejecuta rs.status() en mongosh.

    5. Repetir para cada miembro secundario.

  2. Reduce el primario del set de réplicas.

    1. Degradar al primario.

      Conecta mongosh al primario y utiliza rs.stepDown() para descender al primario y forzar una elección de un nuevo primario:

      rs.stepDown()

    2. Apague el primario reducido.

      Cuando rs.status() indique que el nodo principal se ha desplazado y otro miembro ha asumido el estado PRIMARY, apaga el nodo principal desplazado.

      Para apagar la primaria degradada, utiliza mongosh para conectarte a la primaria y ejecutar el siguiente comando:

      db.adminCommand( { shutdown: 1 } )

    3. Reemplace el binario mongod con el binario 6.0.

    4. Inicie el binario 6.0.

      Inicia el 6.0 con las opciones --configsvr, --replSet, --port, y --bind_ip. Incluye cualquier opción de línea de comandos opcional utilizada en la implementación anterior:

      mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      Si usas un archivo de configuración, actualiza el archivo para especificar sharding.clusterRole: configsvr, replication.replSetName, net.port y net.bindIp; luego, inicia el binario 6.0:

      sharding:
         clusterRole: configsvr
      replication:
         replSetName: <string>
      net:
         port: <port>
         bindIp: localhost,<ip address>
      storage:
         dbpath: <path>

      Incluye cualquier otra configuración que sea adecuada para tu implementación.

4

Actualizar las particiones.

Actualice las particiones una por una.

  1. Para cada set de réplicas de particiones, actualiza los miembros secundarios del set de réplicas, uno a la vez:

    1. Apague la instancia secundaria.

      Para cerrar el proceso mongod, use mongosh para conectarse al nodo del clúster y ejecutar el siguiente comando:

      db.adminCommand( { shutdown: 1 } )

    2. Reemplace el binario 5.0 con el binario 6.0.

      Inicia el binario 6.0 con las opciones --shardsvr, --replSet, --port y --bind_ip. Incluya las opciones de línea de comandos adicionales que correspondan para su implementación:

      mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      Si se utiliza un archivo de configuración, actualiza el archivo para incluir sharding.clusterRole: shardsvr, replication.replSetName, net.port y net.bindIp, y luego inicia el 6.0 binario:

      sharding:
         clusterRole: shardsvr
      replication:
         replSetName: <string>
      net:
         port: <port>
         bindIp: localhost,<ip address>
      storage:
         dbpath: <path>

      Incluye cualquier otra configuración que sea adecuada para tu implementación.

    3. Espere a que el nodo se recupere al estado SECONDARY antes de actualizar el siguiente nodo secundario.

      Para comprobar el estado del nodo, puedes emitir rs.status() en mongosh.

    4. Repetir para cada miembro secundario.

  2. Reduce el primario del set de réplicas.

    Conecte mongosh al principal y utilice rs.stepDown() para rebajar al principal y forzar la elección de un nuevo principal:

    rs.stepDown()

  3. Actualiza el primario bajado.

    Cuando rs.status() muestra que el primario ha dejado su función y otro nodo ha asumido el estado PRIMARY, actualice el primario que ha sido desligado:

    1. Apague el primario reducido.

      Para apagar el primario degradado, use mongosh para conectarse al miembro del set de réplicas y ejecute el siguiente comando:

      db.adminCommand( { shutdown: 1 } )

    2. Reemplace el binario mongod con el binario 6.0.

    3. Inicie el binario 6.0.

      Inicia el binario 6.0 con las opciones --shardsvr, --replSet, --port y --bind_ip. Incluya las opciones de línea de comandos adicionales que correspondan para su implementación:

      mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      Si usas un archivo de configuración, actualiza el archivo para especificar sharding.clusterRole: shardsvr, replication.replSetName, net.port y net.bindIp; luego, inicia el binario 6.0:

      sharding:
         clusterRole: shardsvr
      replication:
         replSetName: <string>
      net:
         port: <port>
         bindIp: localhost,<ip address>
      storage:
         dbpath: <path>

      Incluye cualquier otra configuración que sea adecuada para tu implementación.

5

Actualiza las instancias de mongos.

Reemplaza cada instancia de mongos por el binario 6.0 y reinicia. Incluye cualquier otra configuración que sea apropiada para tu implementación.

Nota

Se debe especificar la opción --bind_ip cuando los nodos del clúster se ejecutan en diferentes hosts o si se conectan clientes remotos al clúster.

mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3> --bind_ip localhost,<ip address>
6

Restablecer el balanceador.

Usando mongosh, conecta a un mongos en el clúster y ejecuta sh.startBalancer() para volver a habilitar el balanceador:

sh.startBalancer()

A partir de MongoDB 6.0.3, no se realiza la división automática de fragmentos. Esto se debe a las mejoras en la política de balanceo. Los comandos de división automática aún existen, pero no ejecutan ninguna operación. Para obtener más información, consulta Cambios en la política de balanceo.

En las versiones de MongoDB anteriores a la 6.0.3, sh.startBalancer() también habilita la división automática para el clúster particionado.

Si no desea habilitar la división automática mientras el balanceador esté activado, también debe ejecutar sh.disableAutoSplit().

Para más información sobre la reactivación del balanceador, consulta Activar el balanceador.

7

Activar las funcionalidades incompatibles con versiones anteriores de 6.0.

En este punto, puedes ejecutar los binarios del 6.0 sin las funcionalidades del 6.0 que sean incompatibles con 5.0.

Para habilitar estas características de 6.0, configure la compatibilidad de características entre versiones (FCV) a 6.0.

Tip

Activar estas características incompatibles con versiones anteriores puede complicar el proceso de degradación, ya que se debe remover cualquier característica incompatible con versiones anteriores que persista antes de realizar la degradación.

Se recomienda que, tras la actualización, se permita que la implementación se ejecute sin habilitar estas características durante un periodo de prueba para asegurar que la probabilidad de reversión sea mínima. Cuando se esté seguro de que la probabilidad de degradación es mínima, se pueden activar estas características.

En una instancia mongos, ejecuta el comando setFeatureCompatibilityVersion en la base de datos admin:

db.adminCommand( { setFeatureCompatibilityVersion: "6.0" } )

Configuración featureCompatibilityVersion (compatibilidad de características entre versiones) : "6.0" realiza de forma implícita una replSetReconfig en cada partición para añadir el campo term al documento de configuración de la réplica de partición.

El comando no se completa hasta que la nueva configuración se propaga a la mayoría de los miembros del set de réplicas.

Este comando debe realizar escrituras en una colección interna del sistema. Si por alguna razón el comando no se completa con éxito, puede volver a ejecutar el comando de manera segura en el mongos, ya que la operación es idempotente.

Nota

Mientras setFeatureCompatibilityVersion se está ejecutando en el clúster particionado, las migraciones, divisiones y combinaciones de fragmentos pueden fallar con ConflictingOperationInProgress.

Cualquier documento huérfano que exista en las particiones se limpiará cuando se configure el setFeatureCompatibilityVersion a 6.0. El proceso de limpieza:

Nota

Consideración adicional

El binario mongos no puede conectarse a mongod instancias cuya compatibilidad de características entre versiones (FCV) sea superior a la del mongos. Por ejemplo, no puedes conectar un MongoDB 5.0 versión mongos a un 6.0 clúster particionado con compatibilidad de características entre versiones establecido en 6.0. Sin embargo, puedes conectar un MongoDB 5.0 versión mongos a un 6.0 clúster fragmentado con compatibilidad de características entre versiones establecido en 5.0.

Procedimientos de actualización adicionales

Volver

Set de réplicas

Next

Degradar de 6.0 a 5.0

En esta página