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
/ /

Actualice un clúster particionado a la versión 7.0

Utiliza este tutorial para actualizar de MongoDB 6.0 a MongoDB 7.0. Para actualizar a una nueva versión dentro de la misma serie de lanzamientos, consulte Actualiza a la última versión de parche autogestionada de MongoDB.

Se debe familiarizar con el contenido de este documento, incluyendo una revisión exhaustiva de los requisitos previos, antes de actualizar a MongoDB 7.0.

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

Si necesitas orientación sobre cómo actualizar a la versión 7.0, Los servicios profesionales de MongoDB ofrecen soporte para actualizaciones de versiones principales para ayudar a garantizar una transición fluida sin interrupciones en tu aplicación MongoDB.

Al actualizar, considere lo siguiente:

Para actualizar una implementación existente de MongoDB a 7.0, se debe estar ejecutando una versión de la serie 6.0.

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

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

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

Antes de actualizar, se puede consultar el documento Cambios de compatibilidad en MongoDB 7.0 para garantizar que las aplicaciones e implementaciones sean compatibles con MongoDB 7.0. Se pueden resolver las incompatibilidades en la 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.

No se puede degradar la versión binaria de la implementación sin asistencia de soporte técnico.

Para aprender más, consulta Degradar de 7.0 a 6.0.

Para actualizar un clúster fragmentado a 7.0, todos los nodos del clúster deben tener al menos la versión 6.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 6.0.

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

Para garantizar que todos los miembros del clúster fragmentado tengan featureCompatibilityVersion configurado en "6.0", conéctese a cada miembro del conjunto de réplicas de fragmentos y a cada miembro del conjunto de réplicas del servidor de configuración y verifique featureCompatibilityVersion:

Tip

Para un clúster fragmentado que tiene habilitado el control de acceso, para ejecutar el siguiente comando contra un miembro del conjunto de réplicas de fragmentos, debe conectarse al miembro como un usuario local de fragmentos.

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

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

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

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

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

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

db.adminCommand( { replSetGetStatus: 1 } )

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.

Si se instaló MongoDB desde los repositorios de MongoDB apt, yum, dnf o zypper, se debería actualizar a 7.0 usando el administrador de Paquetes.

Siga las instrucciones adecuadas de instalación de7.0 para su sistema Linux. Esto requiere agregar un repositorio para la nueva versión y luego realizar el proceso de actualización real.

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.

Consultar instrucciones de instalación 7.0 para obtener más información.

1

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,consulte Deshabilitar el balanceador.

2
  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. Reemplaza el binario 6.0 con el binario 7.0.

    3. Inicie el binario 7.0.

      Inicia el binario 7.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 utilizas un archivo de configuración, actualiza el archivo para especificar sharding.clusterRole: configsvr, replication.replSetName, net.port y net.bindIp, y luego inicia el 7.0 binario:

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

      Incluya cualquier otra configuración según sea necesario para su 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 reductor.

      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 7.0.

    4. Inicie el binario 7.0.

      Inicie 7.0 con --configsvr --replSetlas opciones,, y. Incluya las opciones de línea--port de comandos opcionales utilizadas en la implementación anterior:--bind_ip

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

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

      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.

3

Mejora los fragmentos uno a uno.

Para cada set de réplicas de particiones:

  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. Reemplaza el binario 6.0 con el binario 7.0.

      Inicie el binario 7.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 7.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.

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

    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 reductor.

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

      db.adminCommand( { shutdown: 1 } )
    2. Reemplace el binario mongod. con el 7.0 binario.

    3. Inicie el binario 7.0.

      Inicie el binario 7.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 utilizas un archivo de configuración, actualiza el archivo para especificar sharding.clusterRole: shardsvr, replication.replSetName, net.port y net.bindIp, y luego inicia el 7.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.

4

Importante

Actualice primero todas las instancias del set de réplicas del servidor de configuración (CSRS), luego todos los nodos de la partición y, finalmente, las instancias mongos. Actualizar mongos antes de completar estas actualizaciones puede provocar problemas de compatibilidad.

Reemplace cada instancia con mongos el 7.0 binario y reinicie. Incluya cualquier otra configuración según corresponda para su 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>
5

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

sh.startBalancer()

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

6

En este punto, se pueden ejecutar los binarios 7.0 sin las características 7.0 que son incompatibles con 6.0.

Para activar estas características 7.0, se debe establecer la compatibilidad de características entre versiones (FCV) a 7.0. También debe establecer confirm en verdadero si se actualiza a 7.0 o posterior.

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: "7.0", confirm: true } )

Importante

MongoDB 7.0 introduce el campo confirmar. Debes establecer confirmar en true para que el comando tenga éxito.

La configuración featureCompatibilityVersion (FCV): "7.0" realiza implícitamente un en cada replSetReconfig term fragmento para agregar el campo al documento de configuración de réplica del fragmento.

El comando no se completa hasta que la nueva configuración se propaga a la mayoría de los miembros del conjunto 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 se ejecuta en el clúster fragmentado, las migraciones, divisiones y fusiones de fragmentos pueden setFeatureCompatibilityVersion fallar ConflictingOperationInProgress con.

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

Advertencia

mongos compatibilidad de características entre versiones Compatibility

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 6.0 versión mongos a un 7.0 clúster particionado con compatibilidad de características entre versiones establecido en 7.0. Sin embargo, puedes conectar un MongoDB 6.0 versión mongos a un 7.0 clúster fragmentado con compatibilidad de características entre versiones establecido en 6.0.

Volver

Set de réplicas

En esta página