Rolling upgrade de MongoDB (7.0 → 8.0): replica set y sharded cluster

Actualiza a 8.0 sin interrupción (rolling) un replica set o un sharded cluster de MongoDB 7.0 en funcionamiento: comprobaciones previas (versión, FCV, estado de los miembros, compatibilidad de drivers), copia de seguridad, primero los secondary y después stepDown y el antiguo primary; en el sharded cluster, parada del balancer y el orden config server, shards, mongos. El FCV 8.0 puede dejarse opcionalmente para después del burn-in; se incluyen las opciones de vuelta atrás y sus límites. Para una actualización de patch dentro de la misma versión principal (8.0.x → 8.0.y) el repositorio no cambia y se sigue el mismo orden de miembros; quien venga de 6.0 debe pasar antes a 7.0.

Topología: Replica set (3+ miembros) o sharded cluster (config server + shards + mongos)

Antes de empezar

• Todos …los mongod (config servers y miembros de shard) y los mongos…los miembros… ejecutan 7.0.x y el FCV es 7.0. Si viene de 6.0, actualice antes a 7.0 (no se puede saltar una versión principal).
• Ningún miembro está en estado ROLLBACK/RECOVERING/STARTUP2; los secondary van unos segundos por detrás del primary.
• La ventana del oplog es mucho más larga que la duración del mantenimiento (tiempo que cada miembro permanece apagado), al menos varias horas. Si es corta, el miembro apagado necesitará initial sync al volver.
• Todos los drivers de las aplicaciones están en una versión compatible con MongoDB 8.0 (tabla de compatibilidad de drivers). Los drivers antiguos pueden no conectarse a 8.0 o no admitir los nuevos comportamientos.
• Se ha leído la página de cambios de compatibilidad de 8.0; no usa ninguna función eliminada o modificada (parámetro, comando, comportamiento de consulta). Si ha sido posible, se ha ensayado antes la actualización en un entorno de pruebas.
• Hay una copia de seguridad reciente con la restauración probada (snapshot o mongodump). La ventana de mantenimiento está aprobada.
• Cada miembro tiene espacio libre suficiente en el disco de datos y en /var/log; hay acceso al repositorio de 8.0 (repo.mongodb.org).
• En los config servers y los miembros de shard, mongod se ejecuta con el servicio systemd mongod y con /etc/mongod.conf; en los servidores mongos el nombre del servicio es …. En cada servidor hay un único proceso mongod/mongos.
• El balancer puede detenerse durante la ventana de actualización; no hay migraciones de chunks, resharding ni index builds en curso. No hay cambios de shard key ni de metadatos de colecciones previstos durante el mantenimiento.

Fases de la guía

• Comprobaciones previas — Versión, FCV y rol (todos …los mongod…los miembros…) · Estado de los miembros y retraso de replicación · Estado del cluster, shards y balancer · Colecciones system.buckets no válidas · Comprobación de drivers y compatibilidad · Copia de seguridad y punto de vuelta atrás …
• Cambio de repositorio (todos los miembros) — Añadir el repositorio de 8.0 y desactivar el de 7.0 · Añadir el repositorio de 8.0 y desactivar el de 7.0
• Actualizar los secondary uno a uno — Secondary: …, verificar que no es primary y detener · Secondary: instalar los binarios 8.0 en … · Secondary: ajustar THP para 8.0 en … · Secondary: iniciar … y esperar a que esté en SECONDARY · Secondary: …, verificar que no es primary y detener · Secondary: instalar los binarios 8.0 en … …
• Retirar el primary y actualizarlo — Verificar que los secondary están en 8.0 y sanos · Retirar el primary (stepDown) · Antiguo primary: …, verificar que no es primary y detener · Antiguo primary: instalar los binarios 8.0 en … · Antiguo primary: ajustar THP para 8.0 en … · Antiguo primary: iniciar … y esperar a que esté en SECONDARY
• Detener el balancer — Detener el balancer y verificar que las migraciones han terminado
• Activar el balancer y verificar las versiones — Verificar que todos los componentes están en 8.0 · Volver a activar el balancer
• Verificación — Todos los miembros en 8.0 · Comprobación de la aplicación y de los logs
• featureCompatibilityVersion 8.0 — Subir el FCV a 8.0 · Verificar el FCV
• Vuelta atrás (solo si hay problemas) — Elegir la vía de vuelta atrás · Devolver los binarios a 7.0: … · Vuelta atrás desde la copia de seguridad · Orden de vuelta atrás en un sharded cluster