Familiarícese con el contenido de este documento, incluida una revisión exhaustiva de los requisitos previos, antes de actualizar a MongoDB 5.0.
Los siguientes pasos describen el procedimiento para actualizar un
mongod que es un nodo de partición desde la versión 4.4 hasta la 5.0.
Si se necesita orientación sobre cómo actualizar a 5.0, los servicios profesionales de MongoDB ofrecen soporte para la actualización de versiones principales para ayudar a garantizar una transición sin problemas y sin interrupciones en la aplicación MongoDB.
Recomendaciones de actualizaciones y listas de verificación
Al actualizar, considere lo siguiente:
Ruta de actualización de versión
Para actualizar una implementación existente de MongoDB a la versión 5.0, es necesario ejecutar una versión 4.4.
Para actualizar desde una versión anterior a la serie 4.4, debe actualizar sucesivamente las versiones principales hasta que haya actualizado a la serie 4.4. Por ejemplo, si está ejecutando una serie 4.2, primero debe actualizar a 4.4 antes de poder actualizar a 5.0.
Verifique la compatibilidad del controlador
Antes de actualizar MongoDB, se debe comprobar que se está usando un driver compatible con MongoDB 5.0. Se debe consultar la documentación del driver para el driver específico que se está usando y verificar la compatibilidad con MongoDB 5.0.
Las implementaciones actualizadas que se ejecutan en controladores incompatibles podrían experimentar un comportamiento inesperado o indefinido.
Preparación
Antes de comenzar la actualización, consulte el documento Cambios de compatibilidad en MongoDB 5.0 para garantizar que sus aplicaciones e implementaciones sean compatibles con MongoDB 5.0. Resuelve las incompatibilidades en tu implementación antes de comenzar la actualización.
Antes de actualizar MongoDB, siempre se debe probar la aplicación en un entorno de pruebas antes de implementar la actualización en el entorno de producción.
Consideración de reducción de versión
Una vez que se actualiza a 5.0, si necesitas realizar una degradación, te recomendamos revertir a la última versión de corrección de 4.4.
Requisitos previos
Antes de actualizar tu clúster, consulta las 5.0 consideraciones de rendimiento para identificar posibles impactos al rendimiento al actualizar a 5.0.
Garantizar que la configuración TTL sea válida
Asegúrese de que la configuración de TTL sea válida. Antes de actualizar, remové o corregí todos los índices TTL que tengan expireAfterSeconds configurados en NaN. En MongoDB 5.0 y versiones posteriores, configurar expireAfterSeconds en NaN tiene el mismo efecto que configurar expireAfterSeconds en 0. Para más detalles, consulte TTL expireAfterSeconds Comportamiento cuando se establece en NaN.
Versión de todos los nodos
Para actualizar un clúster fragmentado a 5.0, todos los nodos del clúster deben tener al menos la versión 4.4. El proceso de actualización revisa todos los componentes del clúster y generará advertencias si algún componente ejecuta una versión anterior a 4.4.
Confirmar apagado limpio
Antes de actualizar a un nodo del clúster, confirme que el nodo se haya apagado adecuadamente.
Compatibilidad de características entre versiones
El clúster particionado 4.4 debe tener featureCompatibilityVersion configurado en "4.4".
Para garantizar que todos los miembros del clúster fragmentado tengan featureCompatibilityVersion configurado en "4.4", conéctese a cada miembro del conjunto de réplicas de fragmentos y a cada miembro del conjunto de réplicas del servidor de configuración y verifique featureCompatibilityVersion:
Tip
Para un clúster fragmentado que tiene habilitado el control de acceso, para ejecutar el siguiente comando contra un miembro del conjunto de réplicas de fragmentos, debe conectarse al miembro como un usuario local de fragmentos.
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
Todos los nodos deben devolver un resultado que incluya "featureCompatibilityVersion" : { "version" : "4.4" }.
Para establecer o actualizar featureCompatibilityVersion, ejecute el siguiente comando en mongos:
db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )
Para obtener más información, consulta setFeatureCompatibilityVersion.
Estado del nodo del set de réplicas
Para particiones y servidores de configuración, asegúrate de que ningún miembro del set de réplicas esté en el estado ROLLBACK o RECOVERING.
Realizar una config copia de seguridad de la base de datos
Opcional, pero se recomienda. Como precaución, haz una copia de seguridad de la base de datos config antes de actualizar el clúster particionado.
Descargar archivos binarios 5.0
Usar el gestor de paquetes
Si has instalado MongoDB desde los repositorios de apt, yum, dnf o zypper de MongoDB, debes actualizar a la versión 5.0 utilizando tu administrador de paquetes.
Siga las instrucciones de instalación de la versión 5.0 correspondientes a su sistema Linux. Esto implica agregar un repositorio para la nueva versión y, posteriormente, realizar la actualización.
Descarga 5.0 Binarios manualmente
Si no se ha instalado MongoDB usando un administrador de paquetes, se pueden descargar manualmente los binarios de MongoDB desde el Centro de Descargas de MongoDB.
Consulta instrucciones de instalación para la versión 5.0 para obtener más información.
Proceso de actualización
Advertencia
Si actualizas una instancia existente de MongoDB a MongoDB 5.0.15, es posible que esa instancia no se inicie si fork: true está configurado en el archivo mongod.conf.
El problema de actualización afecta a todas las .deb .rpm instancias de MongoDB que usan paquetes de instalación o. Las instalaciones que usan la versión tarball ().tgz u otros tipos de paquetes no se ven afectadas. Para obtener más información, consulte SERVER-.74345
Para remover la configuración de fork: true, ejecute estos comandos desde una terminal del sistema:
systemctl stop mongod.service sed -i.bak '/fork: true/d' /etc/mongod.conf systemctl start mongod.service
El segundo comando systemctl inicia la instancia actualizada después de eliminar la configuración.
Desactivar el balanceador.
Conecte mongosh a una instancia mongos en el clúster fragmentado y ejecute sh.stopBalancer() para desactivar el balanceador:
sh.stopBalancer()
Nota
Si una migración está en progreso, el sistema completará la migración en curso antes de detener el balanceador. Puedes ejecutar sh.isBalancerRunning() para comprobar el estado actual del balanceador.
Para comprobar que el balanceador esté deshabilitado, ejecuta sh.getBalancerState(), que retorna false si el balanceador está deshabilitado:
sh.getBalancerState()
Para obtener más información sobre cómo deshabilitar el balanceador,consulte Deshabilitar el balanceador.
Actualiza los servidores de configuración.
Actualiza los secundarios del set de réplicas uno a la vez:
Apagar la instancia secundaria
mongody reemplazar el binario 4.4 con el binario 5.0.Inicia el binario 5.0 con el
--configsvr,--replSety--port. Incluya cualquier otra opción utilizada por la implementación.mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> Si utilizas un archivo de configuración, actualiza el archivo para especificar
sharding.clusterRole: configsvr,replication.replSetName,net.portynet.bindIp, y luego inicia el 5.0 binario:sharding: clusterRole: configsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> Incluya cualquier otra configuración según sea necesario para su implementación.
Espere a que el nodo se recupere al estado
SECONDARYantes de actualizar el siguiente miembro secundario. Para comprobar el estado del nodo, emitars.status()enmongosh.Repetir para cada miembro secundario.
Reduce el primario del set de réplicas.
Conecta
mongoshal primario y utilizars.stepDown()para descender al primario y forzar una elección de un nuevo primario:rs.stepDown() Cuando
rs.status()muestra que el primario ha sido degradado y otro nodo ha asumido el estadoPRIMARY, apaga el primario degradado y reemplaza el binariomongodcon el binario 5.0.Inicie el binario 5.0 con las opciones
--configsvr,--replSet,--porty--bind_ip. Incluye cualquier opción de línea de comandos opcional utilizada por la implementación anterior:mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> Si utilizas un archivo de configuración, actualiza el archivo para especificar
sharding.clusterRole: configsvr,replication.replSetName,net.portynet.bindIp, y luego inicia el 5.0 binario:sharding: clusterRole: configsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> Incluye cualquier otra configuración que sea adecuada para tu implementación.
Actualizar las particiones.
Mejora los fragmentos uno a uno.
Para cada set de réplicas de particiones:
Actualiza los secundarios del set de réplicas uno a la vez:
Apaga la instancia
mongody sustituye el binario 4.4 por el binario 5.0.Inicia el binario 5.0 con las opciones
--shardsvr,--replSet,--porty--bind_ip. Incluya las opciones de línea de comandos adicionales que correspondan para su implementación:mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> Si se utiliza un archivo de configuración, actualiza el archivo para incluir
sharding.clusterRole: shardsvr,replication.replSetName,net.portynet.bindIp, y luego inicia el 5.0 binario:sharding: clusterRole: shardsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> Incluye cualquier otra configuración que sea adecuada para tu implementación.
Espere a que el nodo se recupere al estado de
SECONDARYantes de actualizar el siguiente miembro secundario. Para comprobar el estado del nodo, puedes emitirrs.status()enmongosh.Repetir para cada miembro secundario.
Reduce el primario del set de réplicas.
Conecta
mongoshal primario y utilizars.stepDown()para descender al primario y forzar una elección de un nuevo primario:rs.stepDown() Cuando
rs.status()muestre que el primario ha dejado su puesto y otro nodo ha asumido el estadoPRIMARY, actualiza el primario que ha dejado su puesto:Apague la fuente primaria reducida y reemplace el binario con el binario
mongod5.0.Inicia el binario 5.0 con las opciones
--shardsvr,--replSet,--porty--bind_ip. Incluya las opciones de línea de comandos adicionales que correspondan para su implementación:mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> Si utilizas un archivo de configuración, actualiza el archivo para especificar
sharding.clusterRole: shardsvr,replication.replSetName,net.portynet.bindIp, y luego inicia el 5.0 binario:sharding: clusterRole: shardsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> Incluye cualquier otra configuración que sea adecuada para tu implementación.
Actualice las mongos instancias.
Reemplace cada instancia con mongos el 5.0 binario y reinicie. Incluya cualquier otra configuración según corresponda para su implementación.
Nota
Se debe especificar la opción --bind_ip cuando los nodos del clúster se ejecutan en diferentes hosts o si se conectan clientes remotos al clúster.
mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3> --bind_ip localhost,<ip address>
Vuelva a habilitar el balanceador.
Usando mongosh, conecta a un mongos en el clúster y ejecuta sh.startBalancer() para volver a habilitar el balanceador:
sh.startBalancer()
A partir de MongoDB 4.2, sh.startBalancer() también permite la división automática para el clúster fragmentado.
Si no desea habilitar la división automática mientras el balanceador esté activado, también debe ejecutar sh.disableAutoSplit().
Para más información sobre la reactivación del balanceador, consulta Activar el balanceador.
Habilitar funcionalidades incompatibles con versiones anteriores 5.0.
En este punto, puede ejecutar los binarios 5.0 sin las funcionalidades de 5.0 que son incompatibles con 4.4.
Para habilitar estas 5.0 funcionalidades, establezca la compatibilidad de características entre versiones (fCV) en 5.0.
Tip
Activar estas características incompatibles con versiones anteriores puede complicar el proceso de degradación, ya que se debe remover cualquier característica incompatible con versiones anteriores que persista antes de realizar la degradación.
Se recomienda que, tras la actualización, se permita que la implementación se ejecute sin habilitar estas características durante un periodo de prueba para asegurar que la probabilidad de reversión sea mínima. Cuando se esté seguro de que la probabilidad de degradación es mínima, se pueden activar estas características.
En una instancia mongos, ejecuta el comando setFeatureCompatibilityVersion en la base de datos admin:
db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } )
La configuración featureCompatibilityVersion (fCV): "5.0" realiza implícitamente un en cada replSetReconfig term fragmento para agregar el campo al documento de configuración de réplica del fragmento.
El comando no se completa hasta que la nueva configuración se propaga a la mayoría de los miembros del conjunto de réplicas.
Este comando debe realizar escrituras en una colección interna del sistema. Si por alguna razón el comando no se completa con éxito, puede volver a ejecutar el comando de manera segura en el mongos, ya que la operación es idempotente.
Nota
Mientras se ejecuta en el clúster fragmentado, las migraciones, divisiones y fusiones de fragmentos pueden setFeatureCompatibilityVersion fallar ConflictingOperationInProgress con.
Cualquier documento huérfano que exista en las particiones se limpiará cuando se configure el setFeatureCompatibilityVersion a 5.0. El proceso de limpieza:
No impide que se complete la actualización y
Tiene un límite de velocidad. Para mitigar el posible impacto en el rendimiento durante la limpieza de documentos huérfanos, consulta Tuning del Rendimiento de Eliminación de Rangos.
Nota
Consideración adicional
A partir de MongoDB 4.0, el binario mongos fallará al intentar conectarse a instancias mongod cuya compatibilidad de características entre versiones (fCV) sea superior a la del mongos. Por ejemplo, no puedes conectar un MongoDB 4.4 versión mongos a una 5.0 clúster fragmentado con compatibilidad de características entre versiones establecido en 5.0. Sin embargo, puedes conectar un MongoDB 4.4 versión mongos a un 5.0 clúster fragmentado con fCV establecido en 4.4.
Procedimientos de actualización adicionales
Para actualizar un autónomo, consulta Actualizar un autónomo a 5.0.
Para actualizar un set de réplicas, consulta Actualizar un set de réplicas a 5.0.