Categoría: Bases de datos
MongoDB gestionado en vuestra cuenta: replica sets, copias y actualizaciones
Vuestro MongoDB en un replica set que aguanta la caída de un nodo, con copias que se restauran y actualizaciones de una versión a la siguiente, sin sustos.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
En resumen
MongoDB es una base de datos de documentos, muy usada en aplicaciones web y móviles. Administrarla es responder de que esté disponible, rápida y recuperable. Montamos replica sets de tres nodos, copias con recuperación a un momento concreto que restauramos en pruebas, índices, métricas, seguridad y actualizaciones versión a versión, siempre en vuestra cuenta y para vuestro propio uso.
¿Qué nos encargamos de mantener?
MongoDB es fácil de arrancar y por eso muchas instalaciones siguen como el primer día: un solo nodo, sin autenticación, con copias hechas a mano y una versión que ya no recibe parches. Nos encargamos de llevarla a un estado que aguante una caída y un borrado por error.
Replica set
Tres nodos, un primario elegido por votación y dos secundarios al día.
Copias y oplog
Copias coherentes y oplog guardado para volver a un momento concreto.
Índices
Consultas lentas, planes de ejecución e índices que de verdad se usan.
Métricas
mongodb_exporter en Prometheus: retraso, ventana de oplog, caché y conexiones.
Actualizaciones
De una versión mayor a la siguiente, ensayadas antes.
Seguridad
Autenticación, roles por aplicación, TLS y red privada.
¿Por qué tres nodos?
En un replica set, el primario se elige por mayoría de votos. Con tres nodos, si cae uno, los otros dos siguen siendo mayoría, eligen un primario nuevo en segundos y los drivers de la aplicación se reconectan solos. Con dos nodos, la caída de uno deja al otro sin mayoría y sin escrituras. Un árbitro ahorra un servidor, pero no guarda datos y complica las escrituras con mayoría, así que preferimos tres nodos con datos. Revisamos también el writeConcern de la aplicación: con mayoría, una escritura confirmada sobrevive a la caída del primario.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Desarrollo o datos que se pueden regenerar | Un nodo con copias fuera | Sin complejidad, pero sin conmutación |
| Producción normal | Replica set de tres nodos en máquinas o zonas distintas | Aguanta la caída de un nodo sin intervención |
| Datos o escrituras que no caben en un servidor | Clúster con sharding | Reparte la carga, a cambio de bastantes más piezas |
| Ya estáis en AWS, Google Cloud o Azure | MongoDB Atlas | Menos operación; nosotros revisamos índices, alertas y restauraciones |
¿Qué problemas encontramos más a menudo?
- Sin autenticación y abierto a internet: la forma más habitual de perder una base MongoDB entera.
- Un solo nodo en producción: cualquier reinicio del servidor es una caída de la aplicación.
- Ventana de oplog corta: un secundario que se queda atrás unas horas ya no puede ponerse al día y hay que resincronizarlo entero.
- Consultas sin índice: recorridos completos de la colección que disparan la CPU y vacían la caché.
- Documentos que crecen sin límite: arrays que acumulan elementos hasta acercarse al máximo de 16 MB por documento.
- Versión sin soporte: varias versiones mayores por detrás, con un salto pendiente que asusta.
¿Cómo hacemos y probamos las copias?
Hay tres formas y no valen igual. mongodump sirve para bases pequeñas o para exportar una colección, pero es lento y restaurar una base grande puede llevar horas. Las instantáneas del disco son rápidas si se toman de forma coherente, con el journal en el mismo volumen. Para producción usamos Percona Backup for MongoDB, que hace copias físicas o lógicas del replica set y guarda el oplog de forma continua, lo que permite recuperar al minuto anterior a un borrado. Las copias van cifradas a un almacenamiento de objetos en otra cuenta o en otro proveedor. Al menos una vez al mes restauramos en un entorno aparte, comprobamos los recuentos de documentos y los índices, y apuntamos en el informe cuánto ha tardado.
¿Cómo actualizamos de versión?
MongoDB solo se actualiza de una versión mayor a la siguiente: de 6.0 a 7.0 y de 7.0 a 8.0, sin saltos. En cada paso actualizamos primero los secundarios, uno a uno, luego cambiamos el primario y lo actualizamos. La aplicación sigue funcionando durante el proceso. Después dejamos unos días el featureCompatibilityVersion en la versión anterior, por si hay que volver atrás, y solo lo subimos cuando todo va bien; sin ese paso no se puede pasar a la siguiente versión. Antes revisamos que los drivers de vuestras aplicaciones soportan la versión de destino.
¿Qué pasa con la licencia?
MongoDB Community se publica con la licencia SSPL, que impone condiciones a quien ofrece MongoDB como servicio a terceros. Por eso trabajamos siempre igual: la base de datos se instala en vuestra cuenta o en vuestros servidores, para vuestras aplicaciones, y nosotros solo la administramos. No ofrecemos MongoDB como servicio compartido entre clientes. Si la licencia no os encaja, hablamos de Atlas o de pasar a otra base de datos, como PostgreSQL.
¿Cómo vigilamos que todo va bien?
Las alertas cubren nodos caídos, retraso de réplica y disco, como en el SRE como servicio. Las métricas acaban en la monitorización con Grafana y Prometheus.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Replica set en tres servidores cloud o dedicados, en red privada, con copias en Object Storage de Hetzner. | Sin MongoDB gestionado en Hetzner: el replica set, las copias y las actualizaciones las llevamos nosotros. |
| AWS | MongoDB Atlas sobre AWS, o EC2 con un replica set repartido en tres zonas y copias a S3. | Amazon DocumentDB es compatible con parte de la API, pero no es MongoDB: comprobamos antes que vuestra aplicación no use lo que le falta. |
| Google Cloud | MongoDB Atlas sobre Google Cloud, o Compute Engine con replica set y copias a Cloud Storage. | Google Cloud no tiene un MongoDB gestionado propio; la opción gestionada es Atlas. |
| Azure | MongoDB Atlas sobre Azure, o máquinas virtuales con replica set en zonas distintas. | Azure Cosmos DB for MongoDB imita la API con otro motor: sirve en algunos casos y conviene probarlo con vuestras consultas. |
| DigitalOcean | MongoDB gestionado de DigitalOcean con nodos en espera, o Droplets con replica set. | Cómodo para cargas pequeñas y medianas; revisamos versión, tamaño y retención de copias del plan. |
| OVH | Base de datos gestionada de OVHcloud para MongoDB cuando está disponible en vuestra región, o instancias de Public Cloud con replica set. | Comprobamos antes la versión de MongoDB que ofrece. |
| Servidor propio | Replica set en tres servidores o máquinas virtuales vuestras, con las copias en un almacenamiento S3 externo. | Los tres nodos en el mismo host físico no son alta disponibilidad: si cae ese host, cae todo. |
Qué incluye
- Replica set de tres nodos en máquinas o zonas distintas, con prioridades y elecciones revisadas.
- Copias con Percona Backup for MongoDB o instantáneas de disco coherentes, y oplog archivado para recuperar a un momento concreto.
- Restauración de prueba periódica en un entorno aparte, con el tiempo medido en el informe.
- Revisión de consultas lentas con el profiler y explain, e índices que las cubren.
- Métricas con mongodb_exporter y alertas de retraso de réplica, ventana de oplog, disco y conexiones.
- Actualizaciones de una versión mayor a la siguiente, con featureCompatibilityVersion controlado.
- Autenticación activada, un usuario por aplicación con roles mínimos, TLS y acceso solo desde la red privada.
- Plan de migración desde MongoDB Atlas, o hacia Atlas, si es lo que os conviene.
Preguntas frecuentes
¿Qué licencia tiene MongoDB y nos afecta?
MongoDB Community se publica con la licencia SSPL. Para usarla en vuestra propia empresa, como base de datos de vuestras aplicaciones, no supone un problema. Por eso la instalamos y la gestionamos siempre dentro de vuestra cuenta y para vuestro uso; nunca la ofrecemos como servicio compartido entre clientes.
¿Atlas o MongoDB en nuestros propios servidores?
Atlas os quita parches, copias y conmutación, y suele ser lo más sensato si ya estáis en AWS, Google Cloud o Azure y la base de datos es mediana. Montarlo por vuestra cuenta compensa cuando Atlas se encarece con el volumen, cuando vuestro proveedor no lo ofrece, como Hetzner, o cuando queréis los datos en servidores que controláis.
¿Se puede migrar de Atlas sin parar la aplicación?
Casi. Se prepara el replica set nuevo con la misma versión, se copian los datos y se mantiene sincronizado con una herramienta de sincronización continua mientras probáis. El corte se reduce a cambiar la cadena de conexión. Antes revisamos que no uséis funciones exclusivas de Atlas, como su búsqueda integrada.
¿Necesitamos sharding?
Casi nunca al principio. Un replica set bien dimensionado y con buenos índices aguanta mucho más de lo que se suele pensar. El sharding añade servidores de configuración, enrutadores y una clave de reparto que es difícil de cambiar; lo proponemos solo cuando los datos o las escrituras ya no caben en un servidor.
¿Y Percona Server for MongoDB?
Es una distribución compatible con MongoDB Community que añade de serie copias en caliente, auditoría y autenticación con LDAP. Tiene la misma licencia SSPL, así que no cambia nada en ese aspecto; la proponemos cuando necesitáis esas funciones sin pasar a la edición de pago.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el