MongoDB en producción: seguridad, capacidad y operación | Nicolás Garzón
Inicio Wiki MongoDB Producción MongoDB
Producción Explica cómo preparar MongoDB para producción mediante alta disponibilidad, backups, seguridad, observabilidad, capacidad, despliegues y procedimientos de recuperación.
Última actualización Actualizada 25 de jul de 2026
Llevar MongoDB a producción significa diseñar una operación sostenible: topología, seguridad, capacidad, backups, observabilidad, despliegues, ownership y recuperación. Que la aplicación conecte y responda no demuestra que el sistema esté listo.
Vector Search Nota siguiente Actualizaciones y compatibilidad Texto
Copiar requisitos y SLOs
→ topología y capacidad
→ seguridad y datos
→ despliegue controlado
→ observabilidad
→ recuperación y mejora continuaProducción debe tolerar fallos previsibles sin depender de improvisación.
Define antes de elegir infraestructura:
disponibilidad esperada;
latencia p95/p99;
throughput;
RPO;
RTO;
consistencia;
ventanas de mantenimiento;
residencia y retención de datos.
Un catálogo puede tolerar lectura eventual; una confirmación de pago requiere garantías diferentes.
Para workloads críticos usa replica set o servicio administrado equivalente. Evalúa:
número y distribución de voting members;
failure domains;
majority availability;
elections;
oplog window;
hidden/delayed members cuando corresponda;
sharding solo si existe una necesidad demostrada.
Un standalone con restart automático no ofrece alta disponibilidad.
MongoDB Server;
driver;
Mongoose si se usa;
runtime Node.js;
herramientas de backup;
infraestructura.
Conserva una matriz de compatibilidad y política de upgrades. No uses tags flotantes ni componentes fuera de soporte.
red privada o private endpoint;
firewall/allowlist mínima;
sin exposición pública innecesaria;
DNS y TLS validados;
entornos separados;
acceso humano mediante VPN/bastion cuando aplique.
La autenticación no reemplaza aislamiento de red.
Crea usuarios distintos por workload. La aplicación runtime no administra users, clusters ni índices.
least privilege;
rotación;
MFA/federación para humanos;
cuentas personales;
break-glass controlado;
auditoría;
secretos fuera del repositorio e imagen.
TLS debe validar CA y hostname. Define cifrado at rest y, para datos especialmente sensibles, evalúa field-level encryption.
El cifrado no sustituye autorización, minimización ni borrado.
Antes del lanzamiento revisa:
tipos BSON;
null/missing;
límites de arrays;
tamaño documental;
validators;
unique/partial indexes;
snapshots históricos;
versionado de schema;
ownership de migraciones.
TypeScript y Mongoose no protegen escrituras externas por sí solos.
Cada hot path debe tener query shape documentada y explain() validado con volumen representativo.
índices redundantes;
compounds y prefixes;
multikey outliers;
partial/unique semantics;
collation;
TTL;
tamaño y working set;
lifecycle de creación y retirada.
No construyas índices grandes automáticamente al arrancar todas las instancias.
Reutiliza un cliente por proceso. Calcula conexiones totales del fleet y coordina:
max pool size;
checkout timeout;
server selection;
connect/socket timeouts;
maxTimeMS;timeout HTTP;
cancellation.
Un pool mayor puede saturar el servidor. Mide wait queue antes de cambiarlo.
Define política de snapshots/PITR según RPO. Incluye:
datos;
índices y options;
users/roles cuando corresponda;
key vault/KMS;
GridFS;
metadata de sharding;
versiones y migrations.
Almacena copias independientes e inmutables cuando sea posible.
Ejecuta restores periódicos en otro entorno. Mide tiempo total hasta que la aplicación pasa checks funcionales.
pérdida de colección;
corrupción lógica;
pérdida regional;
backup previo a una migration;
datos cifrados;
reconciliación de writes posteriores.
disponibilidad y errores;
latencia por percentiles;
throughput;
pool wait y conexiones;
CPU/cache/eviction;
disk latency y espacio;
replication lag y oplog;
elections;
slow queries y scans;
backups;
crecimiento y costes.
Correlaciona con deploys, index builds y migrations.
condición;
severidad;
owner;
canal;
contexto;
runbook;
criterio de cierre.
Evita alertar por cada métrica. Prioriza síntomas y agotamiento de capacidad.
Las migraciones deben ser:
compatibles con rolling deploy;
reanudables;
idempotentes;
por batches;
observables;
con backup y rollback;
limitadas por carga.
Despliega lectores compatibles antes del backfill y retira formato viejo al final.
validar migrations e índices;
desplegar gradualmente;
verificar readiness;
observar SLOs;
conservar rollback;
no mezclar demasiados cambios;
documentar release.
El readiness debe comprobar dependencias requeridas, no solo que el proceso responde.
Al retirar una instancia:
Texto
Copiar not ready
→ detener tráfico nuevo
→ esperar requests
→ detener workers/cursors
→ cerrar MongoClient
→ terminarPrueba rolling deploy y termination durante queries largas.
datos e índices;
working set;
disco libre;
IOPS;
connections;
oplog;
backups;
restore time;
crecimiento por tenant;
campañas y jobs.
Mantén margen para failover, index builds y migrations.
Necesitas procedimientos para:
primary election;
replication lag;
disco lleno;
slow query;
credential leak;
backup fallido;
restore;
index build problemático;
migration detenida;
caída de región;
pool saturation.
Un runbook debe contener comandos seguros, verificación, rollback, owner y escalamiento.
confirma impacto;
congela cambios no esenciales;
preserva evidencia;
identifica inicio y cambios recientes;
mitiga reversiblemente;
valida datos y SLOs;
comunica;
realiza postmortem sin culpas;
convierte hallazgos en acciones.
No reinicies, limpies cache o elimines índices sin hipótesis.
clasificación;
propósito;
retención;
backups;
exports;
Search/vector indexes;
borrado y anonimización;
acceso de soporte.
Duplicar PII multiplica el trabajo de cumplimiento.
Cada cluster, migration, backup y alerta debe tener owner. Define quién aprueba cambios, quién está de guardia y cómo se escala.
La automatización sin responsabilidad clara solo acelera errores.
replica set/HA probado;
auth, TLS y red privada;
usuarios mínimos;
backups y restore;
índices y explain;
schema validation;
pools/timeouts;
migrations ensayadas;
dashboards/alerts;
runbooks;
budgets/capacity;
load/failover tests;
rollback;
owners.
secondary no puede ponerse al día;
backup existe pero restore supera RTO;
autoscaling oculta scans;
secret rota y workers viejos fallan;
deploy nuevo escribe schema que rollback no entiende;
tenant outlier llena working set;
disk se llena durante index build;
alertas fallan durante el incidente;
restore reintroduce usuarios revocados.
lanzar con standalone;
no definir SLOs;
app con privilegios admin;
MongoDB público;
backups sin restore;
índices creados por intuición;
pool arbitrario;
migrations desde un endpoint;
dashboards sin runbooks;
no probar failover;
creer que Atlas elimina responsabilidad.
Ejecuta carga representativa.
Fuerza election.
Rota credenciales.
Satura pool.
Ejecuta migration interrumpible.
Oculta un índice.
Llena disco en staging.
Restaura backup.
Prueba rollback de app/schema.
Realiza game day y actualiza runbooks.
Producción es una disciplina operacional, no un ambiente. MongoDB debe estar protegido, medido, respaldado, dimensionado y preparado para fallar. La evidencia real viene de pruebas de carga, failover, restore y rollback ejecutadas antes del incidente.
Comprueba lo aprendido
¿Qué decisiones dependen de los SLOs?
¿Por qué standalone no es HA?
¿Qué debe incluir un restore test?
¿Cómo coordinarías timeouts?
¿Qué debe contener un runbook?
¿Qué pruebas ejecutarías antes del lanzamiento?
Actualizaciones y compatibilidad.