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 necesitas realizar un downgrade desde la versión 6.0, hazlo a la última versión de 5.0.
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 6.0 a una de la serie 5.0. Sin embargo, no se admite degradar esa implementación de la serie 5.0 a una de la serie 4.4.
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, consulta Métodos de copia de seguridad para una implementación autogestionada.
Eliminar funciones incompatibles con versiones anteriores
Para realizar una reversión de 6.0 a 5.0, es necesario remover las funcionalidades 6.0 que no son compatibles con 5.0. Para obtener una lista de funcionalidades incompatibles y cómo removerlas, consulta Consideraciones sobre la reversión.
Asegúrese de que no haya operaciones de redistribución en progreso
Asegúrese de que todas las operaciones de repartición se hayan completado correctamente. Si una operación de repartición reciente ha fallado debido a una conmutación por error principal, primero debe ejecutar el cleanupReshardCollectionComando antes de degradar el featureCompatibilityVersion de su clúster fragmentado.
Si una operación de re-fragmentación aún se está ejecutando mientras degrada el featureCompatibilityVersion de su clúster fragmentado, la operación de re-fragmentación no se completará.
Reducir la compatibilidad de características entre versiones (FCV)
Para degradar el FCV de su clúster fragmentado:
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úrese de que ningún nodo tenga un
newlyAddedcampo 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
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"5.0".db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } ) El
setFeatureCompatibilityVersioncomando realiza escrituras en una colección interna del sistema y es idempotente. Si el comando no se completa correctamente, vuelva a intentarlo en lamongosinstancia.Nota
Solución de problemas
Mientras se ejecuta en el clúster fragmentado, las migraciones, divisiones y fusiones de fragmentos pueden
setFeatureCompatibilityVersionfallarConflictingOperationInProgresscon.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 conjunto de réplicas tengan el
featureCompatibilityVersionactualizado, conéctese a cada miembro del conjunto de réplicas y verifique elfeatureCompatibilityVersion:db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) 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.Todos los nodos deben devolver un resultado que incluya:
"featureCompatibilityVersion" : { "version" : "5.0" } Si cualquier nodo retorna un
featureCompatibilityVersionde"6.0", espera a que el nodo retorne la versión"5.0"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 binarios más recientes de la versión 5.0.
Usando un administrador de paquetes o una descarga manual, obtén la versión más reciente de la serie 5.0. Si utiliza un gestor de paquetes, añada un nuevo repositorio para los binarios de la versión 5.0 y luego realice 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 realizar un downgrade desde la versión 6.0, hazlo a la última versión de 5.0.
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 hay una migración en curso, MongoDB la completa antes de detener el balanceador. Para comprobar el estado actual del balanceador,sh.isBalancerRunning() ejecute.
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,consulte Deshabilitar el balanceador.
Degrade cada partición, uno a la vez.
Rebajar los miembros secundarios de la partición, uno a la vez.
Apaga el nodo.
Para cerrar el
mongodproceso, use para conectarse a la implementación y ejecute el siguientemongoshcomando: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 miembro ingrese al 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.
Omita este paso si el conjunto de réplicas no incluye un árbitro.
Degradar el miembro árbitro del clúster fragmentado:
Apaga el nodo.
Para apagar el árbitro, use para conectarse al árbitro y ejecute el siguiente
mongoshcomando: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 miembro ingrese al 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.
mongoshEn, users.stepDown()para retirar las primarias y comenzar una elección para una nueva primaria:rs.stepDown() Verifique que el primario haya bajado.
Ejecuta el siguiente comando:
rs.status() Verifique que el nodo principal haya renunciado y que otro nodo haya asumido el estado
PRIMARY.Apaga el ex 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 5.0.Para iniciar un proceso
mongod, ejecuta el siguiente comando:mongod --dbpath </path-to-mongodb-datafiles> Repita este procedimiento para los fragmentos restantes.
Realiza la degradación de los servidores de configuración.
Degrada los miembros secundarios de la partición del set de réplicas de los servidores de configuración (CSRS) uno a la vez:
Apague 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 miembro ingrese al 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.
mongoshEn, ejecuters.stepDown()para retirarse de la primaria y comenzar una elección para una nueva primaria:rs.stepDown() Verifique que el primario haya bajado.
Ejecuta el siguiente comando:
rs.status() Verifique que el nodo principal haya renunciado y que otro nodo haya asumido el estado
PRIMARY.Apaga el ex 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 5.0.Para iniciar un proceso
mongod, ejecuta el siguiente comando:mongod --dbpath </path-to-mongodb-datafiles>
Vuelva a habilitar el balanceador.
Después de degradar todos los componentes del clúster fragmentado, conéctese a un y ejecute el siguiente comando para volver a habilitar el mongos equilibrador:
sh.startBalancer()
El método sh.startBalancer() también habilita la división automática para el clúster compartido.