MongoDB
Explica cómo actualizar MongoDB, drivers y herramientas con revisión de compatibilidad, feature compatibility version, pruebas, backups y rollback.
Actualizar MongoDB no consiste únicamente en cambiar binarios. Debes coordinar versión del servidor, Feature Compatibility Version —FCV—, drivers, Mongoose, herramientas, topología y comportamiento de la aplicación.
compatibilidad y backup
→ staging
→ upgrade de binarios
→ validación
→ FCV
→ adopción de featuresEl upgrade seguro preserva una ventana de rollback hasta que exista evidencia suficiente.
Mantén una matriz con:
Una combinación puede conectar y aun tener APIs, defaults o features no soportados.
Antes de actualizar revisa:
No bases un upgrade en un tutorial de otra versión.
MongoDB soporta rutas específicas entre versiones. Saltar releases mayores puede no estar permitido.
Define:
versión actual
→ versión intermedia requerida
→ versión objetivoCada etapa necesita backup, validación y observación.
FCV controla qué características persistentes y comportamientos compatibles puede usar el cluster.
Después de actualizar binarios, el cluster suele mantener FCV anterior para conservar compatibilidad mientras validas.
binarios nuevos + FCV anterior
→ ventana de evaluación
→ FCV nuevoNo cambies FCV primero. Activar el nuevo FCV puede introducir formatos o comportamientos que dificulten downgrade.
En replica sets, cuando la ruta lo soporta, se actualizan miembros de forma controlada:
El orden exacto depende de la versión y plataforma.
La coordinación incluye:
mongos;Sigue el procedimiento soportado. Un componente olvidado puede causar errores de routing o administración.
Actualiza el driver por separado cuando sea posible. Revisa:
Despliega primero una versión de driver compatible con ambos servidores para desacoplar riesgos.
Mongoose incluye su propia matriz de compatibilidad y cambios de casting, validation, middleware, strictQuery y TypeScript.
Ejecuta tests sobre:
No actualices MongoDB, driver y Mongoose en una sola release sin una razón fuerte.
Prueba con:
Un staging vacío solo valida que el proceso inicia.
Un upgrade puede cambiar el winning plan. Conserva baseline de:
Compara después y revisa query shapes críticas con explain().
Antes del cambio:
Un backup creado por una versión puede tener requisitos específicos para restore.
No todo upgrade es reversible después de activar FCV o usar features nuevas. Documenta:
No prometas rollback inmediato sin practicarlo.
Después del upgrade, activa features nuevas gradualmente:
upgrade estable
→ FCV nuevo
→ feature flag en staging
→ canary
→ rolloutAsí separas riesgo de infraestructura del riesgo de funcionalidad.
Upgrades y cambios de topología pueden afectar consumidores. Prueba:
No descubras durante producción que el worker no puede reanudar.
Database Tools tienen lifecycle independiente. Verifica mongodump, mongorestore, import/export, monitoring agents y scripts.
Una herramienta antigua puede omitir metadata o no comprender una feature nueva.
En servicios administrados, la plataforma automatiza parte del proceso. Aun debes:
Define:
Un upgrade técnico sigue siendo un cambio de producción.
Un upgrade seguro separa compatibilidad, binarios, FCV y nuevas features. Primero prepara drivers y backups, después actualiza la topología, valida bajo carga y solo entonces cambia FCV. El rollback depende de lo que ya hayas activado o persistido.
Antipatrones de MongoDB.