Docs Menu
Docs Home
/ /
Degradar de 5.0 a 4.4

Degradar el conjunto de réplicas 5.0 a 4.4

Antes de intentar realizar cualquier cambio a una versión inferior, familiarícese con el contenido de este documento.

Importante

Antes de actualizar o degradar un Set de réplicas, asegúrate de que todos los miembros del Set de réplicas estén en funcionamiento. De lo contrario, la actualización o degradación no se completará hasta que se inicien todos los miembros.

Si necesita degradar desde 5.0, degrade a la última versión parcheada de 4.4.

MongoDB solamente soporta degradaciones de una única versión. No se puede retroceder a una versión que esté varias versiones por detrás de la versión actual.

Por ejemplo, puede degradar una implementación de la serie 5.0a una de la serie 4.4. Sin embargo, no se admite degradar esa implementación de la serie 4.4a una de la serie 4.2.

Opcional pero recomendado. Crea una copia de seguridad de tu base de datos.

Si su conjunto de réplicas tiene habilitado el control de acceso, sus privilegios de usuario de degradación deben incluir privilegios para enumerar y administrar índices en las bases de datos. Un usuario con root El rol tiene los privilegios requeridos.

Para degradar de 5.0 a 4.4, debe eliminar las funciones incompatibles que persisten o actualizar las opciones de configuración incompatibles. Estas incluyen:

MongoDB 5.0 cambió el valor predeterminado para las preocupaciones de lectura y escritura a nivel de clúster, y al revertir a MongoDB 4.4, podría restablecer esos valores predeterminados. Considere configurar manualmente la preocupación de lectura y escritura predeterminada de su clúster antes de revertir a la versión anterior:

  • Para configurar manualmente un valor predeterminado para la preocupación de lectura o escritura de un clúster, utilice el setDefaultRWConcern comando.

  • Si su clúster incluye un árbitro y anteriormente había deshabilitado la "Majority" preocupación de lectura para evitar la presión de caché en ciertas situaciones, es posible que desee configurar --enableMajorityReadConcern false o replication.enableMajorityReadConcern: false una vez que baje de versión.

MongoDB 5.0 ahora admite la inclusión de los caracteres . o $ en los nombres de campo de los documentos. Debe eliminar cualquier documento que contenga nombres de campo que incluyan los caracteres . o $ antes de actualizar a MongoDB 4.4.

MongoDB 5.0 habilita la compatibilidad con archivos de datos de zona horaria en formato slim. Si utiliza archivos de datos de zona horaria en formato slim en su implementación, como se proporciona a MongoDB con la --timeZoneInfo opción de línea de comandos o processManagement.timeZoneInfo la configuración del archivo de configuración, debe actualizar a MongoDB.4.4 7 o posterior, o bien revertir sus archivos de datos de zona horaria para que utilicen los archivos de datos anteriores sin formato slim.

Primero, verifique lo siguiente:

  • Asegúrese de que no haya sincronización inicial en curso. Ejecutar el comando setFeatureCompatibilityVersion mientras una sincronización inicial está en curso provocará que la sincronización inicial se reinicie.

  • Asegúrese de que ningún nodo tenga un newlyAdded campo en la configuración de su conjunto de réplicas. Ejecute el siguiente comando en cada nodo del conjunto de réplicas para verificarlo:

    use local
    db.system.replset.find( { "members.newlyAdded" : { $exists : true } } );

    El campo newlyAdded solo aparece en el documento de configuración del conjunto de réplicas de un nodo durante y poco después de una sincronización inicial.

  • Asegúrese de que ningún miembro del conjunto de réplicas esté en estado ROLLBACK RECOVERING o.

A continuación, para revertir la versión del featureCompatibilityVersion de tu set de réplicas:

  1. Conecte un shell mongo al primario.

  2. Bajar de featureCompatibilityVersion a "4.4".

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

    El setFeatureCompatibilityVersion comando realiza escrituras en una colección interna del sistema y es idempotente. Si por alguna razón el comando no se completa correctamente, vuelva a intentarlo en el servidor principal.

  3. Para garantizar que todos los miembros del set de réplicas reflejen el featureCompatibilityVersion actualizado, conéctate a cada miembro del set de réplicas y verifica el featureCompatibilityVersion:

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

    Todos los miembros deben devolver un resultado que incluya:

    "featureCompatibilityVersion" : { "version" : "4.4" }

    Si un nodo devuelve un featureCompatibilityVersion de "5.0", espera a que el nodo refleje la versión "4.4" antes de continuar.

Nota

Los árbitros no replican la admin.system.version colección. Por esta razón, los árbitros siempre tienen una compatibilidad de características entre versiones igual a la versión de degradación del binario, independientemente del valor de la compatibilidad de características entre versiones del Set de réplicas.

Por ejemplo, un árbitro de un clúster de MongoDB 5.0 tiene un valor de compatibilidad de características entre versiones de 4.4.

Para obtener más información sobre el featureCompatibilityVersion valor devuelto,consulte Obtener FeatureCompatibilityVersion.

Los siguientes pasos son necesarios solo si FCV alguna vez se configuró en "5.0".

Elimine todas las 5.0 funciones persistentes que sean incompatibles 4.4 con. Estas incluyen:

Colección de series de tiempo
Eliminar todas las colecciones de series temporales.

Gestión de filtros de auditoría en tiempo de ejecución

  • Restablezca los valores predeterminados del servidor principal del grupo db.admin.runCommand con. El servidor principal debe ser el último servidor de configuración del grupo en actualizarse.

    db.admin.runCommand(
    {
    setAuditConfig: 1,
    filter: {},
    auditAuthorizationSuccess: false
    }
    )

    El documento de configuración también se puede eliminar después de una degradación:

    config.settings.remove({_id: 'audit'});
  • Deshabilite la administración del filtro de auditoría de tiempo de ejecución en cada nodo configurando auditLog.runtimeConfiguration a false en el archivo de configuración del nodo.

  • Actualice los filtros de auditoría para esta instancia en el archivo de configuración local.

Eliminar todas las funciones persistentes que utilizan 5.0 funciones. Estas incluyen, entre otras:

Advertencia

Antes de proceder con el proceso de degradación, asegúrese de que todos los miembros del conjunto de réplicas, incluidos los retrasados, reflejen los cambios de prerrequisitos. Es decir, verifique el featureCompatibilityVersion y la eliminación de las características incompatibles en cada nodo antes de degradar.

1

Usando un gestor de paquetes o una descarga manual, obtenga la última versión de la serie 4.4. Si usa un gestor de paquetes, agregue un nuevo repositorio para los binarios 4.4 y luego realice el proceso de degradación.

Importante

Antes de actualizar o degradar un Set de réplicas, asegúrate de que todos los miembros del Set de réplicas estén en funcionamiento. De lo contrario, la actualización o degradación no se completará hasta que se inicien todos los miembros.

Si necesita degradar desde 5.0, degrade a la última versión parcheada de 4.4.

2

Degradar cada miembro secundario del conjunto de réplicas, uno a la vez:

  1. Ejecute el siguiente comando en mongosh para realizar un apagado limpio, o consulte mongod Detener procesos para obtener formas adicionales de finalizar de forma segura el mongod proceso:

    db.adminCommand( { shutdown: 1 } )
  2. Reemplace el binario 5.0 con el binario 4.4 y reinicie.

  3. Espere a que el miembro se recupere al SECONDARY estado antes de degradar el siguiente secundario. Para comprobar el estado del miembro, utilice el rs.status() método mongosh en.

  4. Una vez que el miembro esté en la etapa SECONDARY, degrada al siguiente secundario.

3

Omita este paso si el conjunto de réplicas no incluye un árbitro.

Degradar el miembro árbitro del conjunto de réplicas:

  1. Ejecute el siguiente comando en mongosh para realizar un apagado limpio, o consulte mongod Detener procesos para obtener formas adicionales de finalizar de forma segura el mongod proceso:

    db.adminCommand( { shutdown: 1 } )
  2. Eliminar el contenido del directorio de datos del árbitro. La storage.dbPath opción de configuración o la opción de línea de comandos especifican el directorio de datos --dbpath del mongod árbitro.

    rm -rf /path/to/mongodb/datafiles/*
  3. Reemplace el binario 5.0 con el binario 4.4 y reinicie.

  4. Espere a que el miembro recupere el ARBITER estado. Para comprobar su estado, conecte al miembro mongosh rs.status() y ejecute el método.

4

Utilice rs.stepDown() en para mongosh reducir el nivel del servidor principal y forzar el procedimiento de conmutación por error normal.

rs.stepDown()

rs.stepDown() acelera el procedimiento de conmutación por error y es preferible a apagar el servidor principal directamente.

5

Cuando muestra que el miembro principal ha dimitido y otro miembro ha asumido rs.status() el PRIMARY estado:

  1. Ejecute el siguiente comando en mongosh para realizar un apagado limpio, o consulte mongod Detener procesos para obtener formas adicionales de finalizar de forma segura el mongod proceso:

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

Volver

Autónomo

En esta página