Se debe familiarizar con el contenido de este documento, incluyendo 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 miembro del fragmento de la versión 4.4 a 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.
Advertencia
Si tus drivers utilizan opcodes heredados que quedaron obsoletos en la versión 3.6, actualiza tus drivers a una versión que utilice opcodes admitidos. Los controladores que usen códigos de operación heredados ya no son compatibles.
Preparación
Antes de actualizar, se puede consultar el documento Cambios de compatibilidad en MongoDB 5.0 para garantizar que las aplicaciones e implementaciones sean compatibles con MongoDB 5.0. Se pueden resolver las incompatibilidades en la 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 actualizado 5.0 a, si necesita cambiar a una versión inferior, le recomendamos hacerlo a la última versión del 4.4 parche.
Nota
Cambio de preocupación de lectura predeterminada
A partir de MongoDB,5.0 es el nivel de preocupación de lectura predeterminado para las operaciones de lectura en los clústeres principal y secundario. Esto podría generar aumentos de latencia en las consultas de conteo que usan un filtro y en las consultas cubiertas en clústeres fragmentados. "local" Para obtener más información sobre este cambio, consulte "local es la preocupación de lectura predeterminada" en la documentación de Cambios de compatibilidad.
Requisitos previos
Antes de actualizar su clúster fragmentado, consulte las 5.0 Consideraciones de rendimiento para conocer los posibles impactos en el rendimiento al actualizar 5.0 a.
Asegúrese de que la configuración TTL sea válida
Asegúrese de que la configuración TTL sea válida. Antes de actualizar, elimine o corrija cualquier índice TTL que tenga expireAfterSeconds establecido NaN en. En MongoDB 5.0 y versiones posteriores, establecer expireAfterSeconds en NaN tiene el mismo efecto que expireAfterSeconds establecer 0 en. Para obtener más información, consulte "Comportamiento TTL expireAfterSeconds cuando se establece en NaN ".
Versión de todos los nodos
Para actualizar un clúster fragmentado 5.0 a, todos los miembros del clúster deben tener al menos la 4.4 versión. El proceso de actualización verifica todos los componentes del clúster y genera advertencias si algún componente ejecuta una versión anterior 4.4 a.
Confirmar apagado limpio
Antes de actualizar un miembro del clúster fragmentado, confirme que el miembro se haya apagado correctamente.
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 configurar o featureCompatibilityVersion actualizar, ejecute el siguiente comando mongos en:
db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )
Para obtener más información, consulta setFeatureCompatibilityVersion.
Estado del nodo del set de réplicas
Para los fragmentos y los servidores de configuración, asegúrese de que ningún miembro del conjunto de réplicas esté en estado ROLLBACK RECOVERING o.
Realizar una config copia de seguridad de la base de datos
Opcional, pero recomendado. Como precaución, realice una copia de seguridad de la config base de datos antes de actualizar el clúster fragmentado.
Descargue 5.0 Binarios
Usar el Administrador de paquetes
Si se instaló MongoDB desde los repositorios de MongoDB apt, yum, dnf o zypper, se debería actualizar a 5.0 usando el administrador de Paquetes.
Se deben seguir las instrucciones de instalación 5.0 adecuadas para el sistema Linux. Esto implicará añadir un repositorio para la nueva versión y, a continuación, realizar el proceso de actualización propiamente dicho.
Descargar 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.
Consultar instrucciones de instalació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 mongos instancia en el clúster fragmentado y ejecute sh.stopBalancer() para deshabilitar el balanceador:
sh.stopBalancer()
Nota
Si hay una migración en curso, el sistema la completará antes de detener el balanceador. Puede ejecutar para comprobar el estado actual del sh.isBalancerRunning() balanceador.
Para verificar que el balanceador esté deshabilitado, ejecute, que devuelve falso si el balanceador está sh.getBalancerState() 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:
Apague la
mongodinstancia secundaria y reemplace el 4.4 binario con el 5.0 binario.Inicie el 5.0 binario
--configsvr--replSetcon, y. Incluya cualquier otra opción que utilice la--portimplementación.mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> Si utiliza un archivo de configuración, actualice el archivo para
sharding.clusterRole: configsvrreplication.replSetNamenet.portespecificar,, y, luego inicienet.bindIpel 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 miembro se recupere al
SECONDARYestado antes de actualizar el siguiente miembro secundario. Para comprobar el estado del miembro, ejecuters.status()mongoshen.Repita esto para cada miembro secundario.
Reduce el primario del set de réplicas.
Conecte
mongosha la primaria y users.stepDown()para reducir la primaria y forzar la elección de una nueva primaria:rs.stepDown() Cuando muestra que el primario ha reducido su estado y otro miembro ha asumido
rs.status()elPRIMARYestado, apague el primario reducido y reemplace el binario conmongodel 5.0 binario.Inicie el 5.0 binario con las
--configsvr--replSetopciones,, y. Incluya cualquier opción de línea de comandos opcional utilizada en la implementación--port--bind_ipanterior:mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> Si utiliza un archivo de configuración, actualice el archivo para
sharding.clusterRole: configsvrreplication.replSetNamenet.portespecificar,, y, luego inicienet.bindIpel 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.
Mejora los fragmentos.
Mejora los fragmentos uno a uno.
Para cada conjunto de réplicas de fragmentos:
Actualiza los secundarios del set de réplicas uno a la vez:
Apague la instancia y reemplace
mongodel 4.4 binario con el 5.0 binario.Inicie el 5.0 binario con las
--shardsvropciones,, y. Incluya las opciones de línea de comandos adicionales que correspondan a su--replSet--port--bind_ipimplementación:mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> Si usa un archivo de configuración, actualice el archivo para
sharding.clusterRole: shardsvrreplication.replSetNamenet.portincluir,, y, luego inicienet.bindIpel 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 miembro se recupere al
SECONDARYestado antes de actualizar el siguiente miembro secundario. Para comprobar el estado del miembro, puede ejecutarrs.status()mongoshen.Repita esto para cada miembro secundario.
Reduce el primario del set de réplicas.
Conecte
mongosha la primaria y users.stepDown()para reducir la primaria y forzar la elección de una nueva primaria: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:Desactiva el primario degradado y reemplaza el binario
mongodcon el binario 5.0.Inicie el 5.0 binario con las
--shardsvropciones,, y. Incluya las opciones de línea de comandos adicionales que correspondan a su--replSet--port--bind_ipimplementación:mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> Si utiliza un archivo de configuración, actualice el archivo para
sharding.clusterRole: shardsvrreplication.replSetNamenet.portespecificar,, y, luego inicienet.bindIpel 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
La opción debe especificarse cuando los miembros del clúster fragmentado se ejecutan en diferentes hosts o si los clientes remotos se conectan al clúster --bind_ip fragmentado.
mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3> --bind_ip localhost,<ip address>
Vuelva a habilitar el balanceador.
mongoshUsando, conéctese a un mongos en el clúster y ejecute sh.startBalancer() para volver a habilitar el balanceador:
sh.startBalancer()
A partir de MongoDB,6.0.3 la división automática de fragmentos no se realiza. Esto se debe a mejoras en la política de balanceo. Los comandos de división automática aún existen, pero no realizan ninguna operación. Para más información, consulte Cambios en la política de balanceo.
En versiones de MongoDB anteriores 6.0.3 a, también habilita la división automática para el clústersh.startBalancer() fragmentado.
Si no desea habilitar la división automática mientras el balanceador está habilitado, también debe sh.disableAutoSplit() ejecutar.
Para obtener más información sobre cómo volver a habilitar el balanceador,consulte Habilitar el balanceador.
Habilitar funcionalidades incompatibles con versiones anteriores 5.0.
En este punto, se pueden ejecutar los binarios 5.0 sin las características 5.0 que son incompatibles con 4.4.
Para habilitar estas 5.0 funciones, configure la versión de compatibilidad de funciones (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 una tasa limitada. Para mitigar el posible impacto en el rendimiento durante la limpieza de documentos huérfanos, consulte Ajuste del rendimiento de la eliminación de rangos.
Nota
Consideración adicional
El binariomongosno puede conectarse a instanciasmongodcuya versión de compatibilidad de características (FCV) sea superior a la demongos. Por ejemplo, no se puede conectar una versiónmongosde MongoDB 4.4 a un clúster fragmentado 5.0 con FCV establecido en 5.0. Sin embargo, sí se puede conectar una versiónmongosde MongoDB 4.4 a un clúster fragmentado 5.0 con FCV establecido en 4.4.
Procedimientos de actualización adicionales
Para actualizar un sistema autónomo, consulte Actualizar un sistema autónomo a 5.0.
Para actualizar un set de réplicas, se puede consultar Actualizar un set de réplicas a 5.0.