Importante
MongoDB 8.3 es la última versión menor. A partir de MongoDB 8.2, las versiones menores están disponibles para implementaciones locales (Community y EA) para casos de uso específicos. Para obtener más información, consulte Versionado de MongoDB.
Para instalar la última versión de MongoDB compatible para uso on-premises, consulta las instrucciones de instalación.
Antes de intentar realizar una degradación, familiarízate con el contenido de esta página.
Ruta de degradación
Importante
Antes de actualizar o degradar un clúster, asegúrate de que todos los nodos del clúster estén en funcionamiento. Si no lo haces, la actualización o degradación no se completará hasta que todos los nodos estén iniciados.
Si necesita degradar desde 8.3, degrade a la última versión parcheada de 8.2.
MongoDB solo admite degradaciones de una única versión a lo largo de versiones adyacentes. No puedes cambiar a una versión que esté varias versiones por detrás de tu versión actual.
Para cualquier versión, mayor o menor, puedes actualizar o degradar a sus vecinos adyacentes. Por ejemplo, puedes degradar desde 8.3 hasta 8.2 o actualizar desde 7.0 hasta 8.0.
Para todas las versiones, tanto mayores como menores, puedes degradar a la versión mayor inmediatamente anterior. Por ejemplo, desde 8.3 hasta 8.0.
Para cualquier versión menor, puedes actualizar a la siguiente versión inmediatamente. Por ejemplo, desde 8.2 hasta 8.3.
Requisitos previos
Antes de comenzar con el procedimiento de degradación, debes completar los siguientes pasos previos.
Crear copia de seguridad
Opcional, pero se recomienda. Crea una copia de seguridad de tu base de datos.
Para aprender cómo crear una copia de seguridad, consulte Métodos de copia de seguridad para una implementación autogestionada.
Remover funcionalidades incompatibles con versiones anteriores
Para pasar de la versión 8.3 a 8.2 la, debe eliminar 8.3 las funciones de la versión que son incompatibles con la 8.2 versión. Para obtener una lista de las funciones incompatibles y cómo eliminarlas, consulte Consideraciones sobre la actualización a una versión anterior.
Asegúrese de que no haya operaciones de redistribución en progreso
Asegúrese de que todas las operaciones de resharding se hayan completado con éxito. Si una operación reciente de reasignación de repartición ha fallado debido a un traspaso principal, primero debes ejecutar el cleanupReshardCollection el comando antes de degradar featureCompatibilityVersion de tu clúster con fragmentación.
Si una operación de cambio de partición sigue en ejecución mientras se realiza una degradación de featureCompatibilityVersion en tu clúster particionado, la operación de cambio de partición no se completará.
Reducir la compatibilidad de características entre versiones (FCV)
Para rebajar el compatibilidad de características entre versiones de tu clúster:
Asegúrate de que no haya una sincronización inicial en curso. Ejecutar el comando
setFeatureCompatibilityVersionmientras se está llevando a cabo una sincronización inicial provoca que la sincronización inicial se reinicie.Asegúrate de que ningún nodo tenga un campo
newlyAddeden su configuración del set de réplicas. Ejecuta el siguiente comando en cada nodo de tu set de réplicas para verificar esto:use local db.system.replset.find( { "members.newlyAdded" : { $exists : true } } ); El campo
newlyAddedsolo 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úrese de que ningún miembro del conjunto de réplicas esté en el
ROLLBACKni en elRECOVERINGestado.Degrade el
featureCompatibilityVersiona"8.2".Importante
Verifique que haya eliminado todas las funciones incompatibles con versiones anteriores antes de degradar la versión binaria. Asegúrese de evaluar su ruta de actualización antes de continuar.
db.adminCommand( { setFeatureCompatibilityVersion: "8.2", confirm: true } ) El comando
setFeatureCompatibilityVersionrealiza escrituras en una colección interna del sistema y es idempotente. Si la orden no se completa correctamente, intenta nuevamente la orden en la instancia demongos.Nota
Solución de problemas
Mientras
setFeatureCompatibilityVersionse está ejecutando en el clúster particionado, las migraciones, divisiones y combinaciones de fragmentos pueden fallar conConflictingOperationInProgress.Si
setFeatureCompatibilityVersionfalla con un errorManualInterventionRequired, y el clúster se realizó recientemente una operación de greyshard que falló debido a una elección, debes ejecutar el comandocleanupReshardCollectionantes de intentar ejecutarsetFeatureCompatibilityVersionnuevamente.
Para garantizar que todos los miembros del set de réplicas tengan el
featureCompatibilityVersionactualizado, conecte con cada miembro del set de réplicas y verifique elfeatureCompatibilityVersion:Tip
Control de acceso
Para un clúster con acceso controlado habilitado, para ejecutar el
adminCommanden un nodo de un set de réplicas de particiones, debes conectarte al nodo como usuario local de particiones.db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) "featureCompatibilityVersion" : { "version" : "8.2" } Si cualquier nodo retorna un
featureCompatibilityVersionde"8.3", espera a que el nodo retorne la versión"8.2"antes de continuar.
Para obtener más información sobre el valor de featureCompatibilityVersion devuelto, consulta Obtener la Version de Compatibilidad de Características.
Procedimiento de reversión
Advertencia
Antes de proceder con el procedimiento de reversión, asegúrate de que todos los nodos del clúster, incluidos los miembros del set de réplicas retardado, tienen los cambios previos requeridos. Para hacer eso, verifica el featureCompatibilityVersion y luego remueve las funcionalidades incompatibles de cada nodo antes de hacer la rebaja de versión.
Descarga los últimos binarios 8.2
Mediante un gestor de paquetes o una descarga manual, obtenga la última versión de 8.2. Si utiliza un gestor de paquetes, añada un nuevo repositorio para los binarios de 8.2 y, a continuación, realice el proceso de degradación.
Importante
Antes de actualizar o degradar un clúster, asegúrate de que todos los nodos del clúster estén en funcionamiento. Si no lo hace, la actualización o degradación no se completará hasta que todos los nodos estén iniciados.
Si necesita degradar desde 8.3, degrade a la última versión parcheada de 8.2.
Desactivar el balanceador
Para desactivar el balanceador, conecta mongosh a una instancia mongos en el clúster particionado y ejecuta el siguiente comando:
sh.stopBalancer()
Nota
Si una migración está en curso, MongoDB completa la migración en curso antes de detener el balanceador. Para comprobar el estado actual del equilibrador, ejecuta sh.isBalancerRunning().
Para verificar que el balanceador esté desactivado, ejecuta el siguiente comando:
sh.getBalancerState()
sh.getBalancerState() retorna false si el balanceador está deshabilitado.
Para obtener más información sobre cómo deshabilitar el balanceador, consulta Deshabilitar el balanceador.
Degradación de cada fragmento, uno por uno.
Rebajar los miembros secundarios de la partición, uno a la vez.
Apaga el nodo.
Para apagar el proceso
mongod, utilizamongoshpara conectarte a la implementación y ejecutar el siguiente comando:db.adminCommand( { shutdown: 1 } ) Reinicia el nodo.
Para iniciar un proceso
mongod, ejecuta el siguiente comando:mongod --dbpath </path-to-data-folder> Espere a que el nodo entre en el estado
SECONDARY.Antes de degradar el siguiente secundario, espere a que el nodo se recupere al estado
SECONDARY. Para verificar el estado del nodo, utiliza el métodors.status()enmongosh.Repite los pasos anteriores para revertir la versión de cada miembro secundario.
Degradar el árbitro de particiones, si lo hay.
Omite este paso si el conjunto de réplicas no incluye un árbitro.
Degradar el árbitro nodo del clúster:
Apaga el nodo.
Para apagar el árbitro, utiliza
mongoshpara conectarte al árbitro y ejecutar el siguiente comando:db.adminCommand( { shutdown: 1 } ) Borrar el contenido del directorio de datos del árbitro.
Para encontrar el directorio de datos del árbitro
mongod, revise la configuración de lastorage.dbPatho la opción de línea de comandos--dbpath.Ejecuta el siguiente comando:
rm -rf /path/to/mongodb/datafiles/* Reinicia el árbitro.
Para iniciar un proceso
mongod, ejecuta el siguiente comando:mongod --dbpath </path-to-mongodb-datafiles> Espere a que el nodo entre en el estado
ARBITER.Antes de hacer un downgrade, espere a que el nodo se recupere al estado
ARBITER. Para verificar el estado del nodo, utiliza el métodors.status()enmongosh.
Degrade el primario de la partición.
Degradar al primario.
En
mongosh, se usars.stepDown()para desocupar el primario y comenzar una elección para un nuevo primario:rs.stepDown() Verifique que el primario se haya desactivado.
Ejecuta el siguiente comando:
rs.status() Verifique que el nodo principal haya renunciado y que otro nodo haya asumido el estado
PRIMARY.Apague el antiguo miembro principal.
Para apagar el antiguo primario, conéctate a la implementación utilizando
mongoshy ejecuta el siguiente comando:db.adminCommand( { shutdown: 1 } ) Reinicia el
mongodcon el binario 8.2.Para iniciar un proceso
mongod, ejecuta el siguiente comando:mongod --dbpath </path-to-mongodb-datafiles> Repita para las particiones restantes.
Rebajar la configuración de los servidores
Degrada los miembros secundarios de la partición del set de réplicas de los servidores de configuración (CSRS) uno a la vez:
Apaga el secundario.
Conéctate al secundario y ejecuta el siguiente comando:
db.adminCommand( { shutdown: 1 } ) Reinicia el nodo.
Para iniciar un proceso
mongod, ejecuta el siguiente comando:mongod --dbpath </path-to-data-folder> Espere a que el nodo entre en el estado
SECONDARY.Antes de degradar el siguiente secundario, espere a que el nodo se recupere al estado
SECONDARY. Para verificar el estado del nodo, utiliza el métodors.status()enmongosh.Repite los pasos anteriores para revertir la versión de cada miembro secundario.
Retrocede el primario del servidor de configuración.
Degradar al primario.
En
mongosh, ejecutars.stepDown()para descender al primario e iniciar una elección para un nuevo primario:rs.stepDown() Verifique que el primario se haya desactivado.
Ejecuta el siguiente comando:
rs.status() Verifique que el nodo principal haya renunciado y que otro nodo haya asumido el estado
PRIMARY.Apague el antiguo miembro principal.
Para apagar el antiguo primario, conéctate a la implementación utilizando
mongoshy ejecuta el siguiente comando:db.adminCommand( { shutdown: 1 } ) Reinicia el
mongodcon el binario 8.2.Para iniciar un proceso
mongod, ejecuta el siguiente comando:mongod --dbpath </path-to-mongodb-datafiles>
Vuelva a habilitar el equilibrador
Después de bajar la versión de todos los componentes del clúster con particionado, conéctese a un mongos y ejecute el siguiente comando para volver a habilitar el balanceador:
sh.startBalancer()
El método sh.startBalancer() también habilita la división automática para el clúster compartido.