Antes de que intentes cualquier degradación, familiarízate con el contenido de este documento.
Ruta de degradación
Si necesitas bajar de la versión 5.0, bájate a la última versión de parche de la 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, puedes rebajar una implementación de la serie 5.0 a la serie 4.4. Sin embargo, no se admite la conversión adicional de esa implementación de la serie 4.4 a una implementación de la serie 4.2.
Crear copia de seguridad
Opcional, pero se recomienda. Crea una copia de seguridad de tu base de datos.
Control de acceso
Si tu implementación tiene el control de acceso habilitado, tus privilegios de reducción deben incluir privilegios para enumerar y gestionar índices en todas las bases de datos. Un usuario con root El rol tiene los privilegios requeridos.
Requisitos previos
Para hacer downgrade de la versión 5.0 a la 4.4, debes remover las funcionalidades incompatibles que están guardadas y/o actualizar la configuración incompatible. Estos incluyen:
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 falseoreplication.enableMajorityReadConcern: falseuna vez que realices el downgrade.
2. Campos de documentos con . o $ caracteres
MongoDB 5.0 agrega soporte para incluir los caracteres . o $ en los nombres de los campos de los documentos. Debes borrar cualquier documento que contenga nombres de campos que incluyan los caracteres . o $ antes de realizar una degradación 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 compatibilidad de características entre versiones (compatibilidad de características entre versiones)
Para degradar el featureCompatibilityVersion de tu autónomo:
Degrade el
featureCompatibilityVersiona"4.4".db.adminCommand({setFeatureCompatibilityVersion: "4.4"}) El comando
setFeatureCompatibilityVersionrealiza operaciones de guardado en una colección del sistema interno y es idempotente. Si por alguna razón la instrucción no se completa con éxito, retrase la instrucción en la instanciamongod.
5. Remover la compatibilidad de características entre versiones 5.0 funcionalidades persistentes
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
- Remueva todas las colecciones de series de tiempo.
- Gestión de filtros de auditoría en tiempo de ejecución
Desactiva la gestión del filtro de auditoría en tiempo de ejecución configurando
auditLog.runtimeConfigurationenfalseen 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
Remueva todas las funcionalidades guardadas que usen funcionalidades de la versión 5.0. Estos incluyen, pero no se limitan a:
Si alguna definición de vista incluye operadores 5.0, como
$dateAddo$sampleRate, deben ser removidos. Consulta Nuevos operadores de agregación para la lista completa.
Procedimiento
Advertencia
Antes de continuar con el procedimiento de degradación, asegúrate de que se hayan completado los requisitos previos.
Descargar los últimos binarios 4.4.
Utilizando un administrador de paquetes o una descarga manual, obtén la versión más reciente de la serie 4.4. Si utilizas un gestor de paquetes, añade un nuevo repositorio para los binarios de la versión 4.4 y luego realiza el proceso real 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 necesitas bajar de la versión 5.0, bájate a la última versión de parche de la 4.4.
Apaga la instancia mongod.
Para cerrar correctamente el proceso de mongod, conecta mongosh a la instancia y ejecuta:
db.adminCommand( { shutdown: 1 } )
Un apagado limpio de un mongod completa todas las operaciones pendientes, guarda todos los datos en archivos de datos y cierra todos los archivos de datos.
Actualizar archivos de configuración.
Desactive cualquier funcionalidades configurable 5.0 actualizando el archivo de configuración de la instancia mongod antes de reiniciar.
Reinicia con el último 4.4 mongod instancia.
Reemplaza el binario 5.0 con el binario descargado 4.4 mongod y reinicia.