MongoDB lanza nuevas versiones periódicamente. La forma en que recibes esas versiones y el control que tienes sobre los plazos de lanzamiento dependen de cómo ejecutes MongoDB. Según el tipo de implementación, deberás prepararte para ejecutar una nueva versión de diferentes maneras.
Esta página explica qué significan los números de versión de MongoDB, qué son los tipos de lanzamiento y cómo funcionan las actualizaciones en términos generales. Para conocer los procedimientos y las políticas específicas de su implementación, consulte los enlaces que aparecen a lo largo del texto.
Cómo se numeran las versiones de MongoDB
Los números de versión de MongoDB tienen el formato X.Y.Z:
X es la versión principal. Un cambio aquí indica una versión que puede incluir cambios incompatibles con versiones anteriores y nuevas funciones que conservan datos en formatos que las versiones anteriores no pueden leer.
Y es la versión menor. Las versiones menores ofrecen mejoras incrementales entre las versiones principales, y su disponibilidad depende del tipo de implementación.
Z es la versión de parche. Las versiones de parche contienen correcciones y son compatibles con versiones anteriores dentro de su serie de versiones.
Los controladores, MongoDB Shell y las herramientas de base de datos de MongoDB se versionan independientemente del servidor de base de datos. El número de versión de un controlador no se corresponde con el número de versión del servidor. Para saber qué versiones de controladores son compatibles con qué versiones de servidor, consulte la página de compatibilidad de su controlador.
Tipos de lanzamiento
Versiones principales
Las versiones principales introducen nuevas funciones y pueden incluir cambios incompatibles con versiones anteriores. MongoDB admite versiones principales tanto para implementaciones Atlas como para implementaciones autogestionadas.
Versiones menores
Las actualizaciones menores ofrecen nuevas funcionalidades con mayor frecuencia entre las actualizaciones principales.
A partir de MongoDB 8.2, las versiones menores están disponibles para las implementaciones autogestionadas de Atlas Auto Upgrade, Enterprise Advanced y Community. A partir de MongoDB 9.0, las versiones menores solo están disponibles a través de Atlas Auto Upgrade.
Nota
Es posible que las versiones menores no sean compatibles con todas las funciones, en particular con Atlas Live Migration y mongosync.
Lanzamientos de actualización de funciones
A partir de MongoDB 9.0, las actualizaciones de características son versiones menores anuales, numeradas x.5, disponibles para Atlas y las implementaciones autogestionadas. Estas actualizaciones permiten a las actualizaciones manuales de Atlas y a las implementaciones autogestionadas obtener características incrementales sin tener que esperar a la siguiente versión principal. Mantienen el mismo ciclo de vida y la misma elegibilidad para el soporte de ciclo de vida extendido que la versión principal a la que extienden.
Importante
Para recibir todas las versiones menores de MongoDB 9.0 y posteriores, configure su clúster de Atlas en Latest Version With Auto Upgrades. Todas las demás implementaciones solo son elegibles para la actualización de características, no para otras versiones menores.
Versiones de parches
Las actualizaciones incluyen correcciones y solo son compatibles con versiones anteriores dentro de su propia serie de versiones principales y secundarias. Siempre debe usar la última actualización disponible para su versión principal y secundaria.
Candidatos a lanzamiento
Las versiones candidatas son compilaciones previas al lanzamiento destinadas a evaluar nuevas funcionalidades. No son aptas para implementaciones en producción.
Para obtener más información sobre cómo MongoDB numera y programa las versiones, consulte la sección de Control de versiones de MongoDB.
Cómo llegan las versiones a su implementación
Las versiones de MongoDB llegan a Atlas antes de estar disponibles para implementaciones autogestionadas.
Importante
Un clúster de Atlas Auto Upgrade configurado para recibir las versiones más recientes puede ejecutar una versión antes de que esta esté disponible para su descarga e instalación por parte del usuario.
Lo que esto significa en la práctica depende de cómo ejecutes MongoDB:
Los clústeres de actualización manual de Atlas mantienen un ritmo de actualización de versión principal que usted controla.
Los clústeres deAtlas Auto Upgrade reciben las nuevas versiones automáticamente a medida que Atlas las implementa.
Las implementacionesautogestionadas (Enterprise Advanced o Community) le permiten elegir cuándo descargar e instalar cada versión. Nada cambia hasta que usted actúe.
Compatibilidad de características entre versiones
Actualizar los binarios de MongoDB y habilitar las funciones de la nueva versión son dos pasos separados.
La versión de compatibilidad de funciones (FCV) controla si se habilitan las funciones que escriben datos en un formato que las versiones anteriores no pueden leer. Después de actualizar los binarios, la implementación continúa ejecutándose con la FCV anterior hasta que la actualice. Esto es intencional: mientras la FCV se mantenga en la versión anterior, usted conserva la posibilidad de revertir a una versión anterior.
Nota
En Atlas Auto Upgrade, Atlas actualiza automáticamente el FCV para que coincida con cada nueva versión de MongoDB tras una revisión automatizada de las señales de despliegue de los binarios de MongoDB. Usted no controla el FCV.
Aumentar el FCV es el punto de no retorno. Una vez habilitadas las funciones que conservan los datos en el nuevo formato, no es posible revertir la actualización en Atlas.
Para consultar la referencia del comando, vea setFeatureCompatibilityVersion en el Manual de MongoDB. Para saber cómo funciona FCV en Atlas, incluyendo cómo fijar FCV antes de una actualización, consulte Actualizar la versión principal de MongoDB para un clúster.
Ciclo de vida del soporte y fin de vida
Cada versión principal de MongoDB cuenta con soporte durante cinco años, con un período opcional de soporte extendido (ELS) de dos años disponible para los clientes de Enterprise Advanced. Cuando una versión llega al final de su ciclo de vida, deja de recibir correcciones, incluidas las de seguridad, y MongoDB deja de mantener su documentación.
El manejo difiere según el tipo de implementación:
En Atlas, MongoDB te notifica la fecha límite de compatibilidad de tu versión antes de que esta llegue al final de su ciclo de vida. Después de esa fecha, Atlas actualiza tus clústeres a la versión de destino predeterminada actual de MongoDB.
Importante
La versión de destino predeterminada actual para MongoDB no siempre es la siguiente versión principal.
Las implementacionesautogestionadas requieren que actualice antes del final de su ciclo de vida.
Para ver qué versiones son compatibles actualmente con cada plataforma, consulte Plataformas compatibles para MongoDB Enterprise o Plataformas compatibles para MongoDB Community.
Elige tu ruta de actualización
Si corres | Cadencia de versiones | Comience aquí |
|---|---|---|
Actualización del manual de Atlas | Tú decides cuándo pasar a la siguiente versión principal. | |
Actualización automática de Atlas | Atlas se actualiza automáticamente. Utilice las fases de mantenimiento para controlar el orden en todos los entornos. | |
Enterprise Advanced | Tú eliges cuándo. | |
Community | Tú eliges cuándo. |
Consideraciones para la actualización autogestionada
Para implementaciones autogestionadas, los procedimientos de actualización difieren según la topología. La página de actualización de cada versión enlaza con los procedimientos para clústeres independientes, conjuntos de réplicas y clústeres fragmentados.
En las versiones de MongoDB anteriores a 9.0, no se pueden omitir las versiones menores al actualizar una implementación autogestionada. Para pasar de una versión menor a otra, es necesario actualizar cada una de ellas en secuencia.
A partir de MongoDB 9.0, las implementaciones Enterprise Advanced reciben únicamente la actualización anual de características, además de las versiones principales. Ya no existe una secuencia de actualizaciones menores que se puedan omitir dentro de un ciclo de lanzamiento.
Antes de actualizar
Independientemente del tipo de implementación, hay tres cosas que conviene hacer antes de una actualización de versión importante:
Prueba tu aplicación con la nueva versión antes de que entre en producción.
La forma de lograr esto depende de su implementación:
Autogestionado: actualice primero una implementación que no sea de producción.
Actualización manual de Atlas: cree un clúster de prueba que ejecute la versión de destino y realice pruebas con él. Consulte la sección "Actualizar la versión principal de MongoDB para un clúster".
Actualización automática de Atlas: puede utilizar oleadas de mantenimiento para secuenciar los entornos de preproducción y producción, pero es posible que no detengan el despliegue y no le brinden un control total sobre el momento de la actualización.
Importante
Si necesita más tiempo para validar una versión, utilice un ciclo de versiones principales. Para obtener más información sobre las fases de mantenimiento, consulte la sección "Administrar el mantenimiento del clúster".
Rebajas
La degradación de la versión está restringida, y estas restricciones varían según el tipo de implementación. Seleccione su tipo de implementación para ver las restricciones que le corresponden.
Para realizar una degradación, es necesario que el FCV no se haya aumentado o que se haya fijado antes de la actualización original.
Un clúster solo puede degradar a la versión inmediatamente anterior, ya sea la versión principal anterior o la actualización de características de esa versión principal, y las degradaciones no se pueden encadenar a través de varias versiones.
Un clúster que utiliza una actualización de características puede volver a su propia versión principal.
Salvo contadas excepciones, una degradación se aplica a la última versión de parche de la versión de destino.
Tras una degradación, las funciones introducidas en la versión más reciente dejan de estar disponibles, y MongoDB no admite una segunda degradación desde la nueva versión inferior.
No se pueden degradar los clústeres.
Nota
Para pasar a un ciclo de versiones principales que permita la reversión a versiones anteriores, realice el cambio como una acción de autoservicio después del lanzamiento de la versión principal (
x.0.0) y antes del primer lanzamiento menor de ese ciclo (x.1.0). Para obtener más información, consulte Última versión con actualizaciones automáticas.
- Las reversiones solo son compatibles entre versiones adyacentes y requieren procedimientos específicos para la configuración de su clúster.
Para realizar una degradación, es necesario que el FCV no se haya aumentado o que se haya fijado antes de la actualización original.
Un clúster solo puede degradar a la versión inmediatamente anterior, ya sea la versión principal anterior o la actualización de características de esa versión principal, y las degradaciones no se pueden encadenar a través de varias versiones.
Un clúster que utiliza una actualización de características puede volver a su propia versión principal.
Salvo contadas excepciones, una degradación se aplica a la última versión de parche de la versión de destino.
Tras una degradación, las funciones introducidas en la versión más reciente dejan de estar disponibles, y MongoDB no admite una segunda degradación desde la nueva versión inferior.
Obtén más información
Control de versiones de MongoDB para la numeración y la periodicidad de las versiones en detalle.
Notas de la versión para cada versión, cambios de compatibilidad y procedimientos de actualización y degradación.
Versiones de MongoDB en Atlas para ver las opciones de cadencia de lanzamiento de Atlas