Degradar el conjunto de réplicas de la versión 5.0 a la versión 4.4

1. Niveles de confirmación de lectura y escritura (read and write concerns) por defecto del clúster

MongoDB 5.0 cambió el valor predeterminado para el nivel de confirmación de lectura y escritura (write concern) a nivel de clúster, y la reversión a MongoDB 4.4 podría cambiar esos valores predeterminados nuevamente. Considera configurar manualmente el nivel de confirmación de lectura y escritura (read and write concern) por defecto de tu clúster antes de realizar el downgrade:

• Para configurar manualmente un valor por defecto para el nivel de confirmación de lectura o escritura (write concern) de un clúster, utiliza el comando setDefaultRWConcern.

• Si tu clúster incluye un árbitro, y previamente habías desactivado el nivel de consistencia de lectura "Majority" para evitar la presión de caché en ciertas situaciones, puedes querer configurar --enableMajorityReadConcern false o replication.enableMajorityReadConcern: false una vez que realices el downgrade.

2. Campos de documento con . o $ caracteres

MongoDB 5.0 permite incluir 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.

3. Archivos de datos de zona horaria en formato slim

MongoDB 5.0 permite el soporte de archivos de datos de zona horaria en formato reducido. Si se utilizan archivos de datos de zona horaria en formato slim en su implementación, tal como se proporciona a MongoDB con la opción de línea de comandos --timeZoneInfo o la configuración de archivo processManagement.timeZoneInfo, debe degradar a MongoDB 4.4.7 o superior, o bien revertir los archivos de datos de zona horaria para utilizar los archivos de datos anteriores en formato no slim.

4. Degradar la versión de compatibilidad de funciones (fCV)

Primero, verifica 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 set de réplicas de un nodo durante y poco después de una sincronización inicial.

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

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

1. Conecte una carcasa a la mongo primaria.

2. Degrade el 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 nodos 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.

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

5. Eliminar las funciones persistentes de fCV 5.0

Los siguientes pasos solo son necesarios si alguna vez se ha configurado la compatibilidad de características entre versiones en "5.0".

Remueva todas las funcionalidades persistentes de la versión 5.0 que sean incompatibles con la versión 4.4. Esto incluye:

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

• Restablece la configuración por defecto en el servidor primario en el grupo con db.admin.runCommand. El primario debería 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 la 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 de esta instancia en el archivo de configuración local.

6. Remover Funcionalidades de la versión 5.0

Eliminar todas las funciones persistentes que utilizan funciones de la versión 5.0. Estas incluyen, entre otras:

• Si alguna definición de vista incluye operadores 5.0, como $dateAdd o $sampleRate, deben ser removidos. Consulta Nuevos operadores de agregación para la lista completa.