Operación diaria y escenarios de fallo de MongoDB (replica set y sharded cluster)

No es una instalación: runbook por escenarios para administrar a diario un replica set y un sharded cluster de MongoDB ya instalados y recuperarlos cuando fallan. Comprobación de estado, alta/baja de miembros, miembros priority/hidden/delayed, sustitución del arbiter por un miembro con datos, resincronización de un miembro rezagado, force reconfig tras perder la mayoría, stepDown planificado, tamaño del oplog, FCV; alta/baja de shards, balancer, jumbo chunks y reshardCollection. Si no sabe qué hacer, empiece por la comprobación de estado; la restauración desde backup, la configuración de seguridad y la actualización de versión mayor se tratan en guías de MongoDB independientes.

Topología: Replica set (3+ miembros) o sharded cluster (config server + replica sets de shard + mongos)

Escenarios

• Comprobación de estado: miembros, retraso, ventana del oplog (shards y balancer en sharded) — Solo lectura: estado de los miembros, retraso de replicación, ventana del oplog, configuración; en un sharded cluster, la lista de shards, el balancer y la distribución de chunks. Empiece aquí si no está seguro de qué hacer.
• Añadir un miembro nuevo al replica set (initial sync) — Se ha preparado un servidor nuevo (misma versión, keyfile, replSetName); se añade con priority 0 / votes 0 y recibe voto y priority cuando termina el initial sync y pasa a SECONDARY. Sin downtime.
• Quitar un miembro del replica set — El servidor se retira o se ha perdido de forma permanente: el miembro se elimina de la configuración y se comprueba que los votos restantes mantienen la mayoría. Si es el primary, primero stepDown.
• Cambiar el rol de un miembro: priority, hidden, delayed (diferido) — Cambiar la prioridad de un miembro para ser primary, convertirlo en miembro oculto (hidden) para informes/backup o en miembro diferido (delayed) como protección frente a borrados accidentales, o devolverlo a la normalidad.
• Sustituir el arbiter por un miembro con datos (PSA → PSS) — Replica set con primary + secondary + arbiter: cuando cae un miembro con datos, las escrituras majority y la presión sobre la caché se convierten en un problema. Se añade un miembro con datos nuevo y se quita el arbiter.
• Resincronizar un miembro rezagado o dañado (resync) — El miembro está bloqueado en RECOVERING e indica 'too stale to catch up', o sus ficheros de datos están dañados: se vacía el directorio de datos del miembro y se resincroniza desde cero con un initial sync. Los demás miembros siguen funcionando.
• Pérdida de la mayoría: reconfigurar a la fuerza con los miembros restantes (force reconfig) — La mayoría de los miembros se ha perdido de forma permanente (pérdida de sitio/servidor) y los restantes no pueden elegir primary: rs.reconfig(cfg, {force: true}) con los miembros restantes. Último recurso; un uso incorrecto conlleva riesgo de pérdida de datos y split brain.
• Cambio planificado de primary (rs.stepDown, hacer primary a un miembro concreto) — Hay que hacer mantenimiento/aplicar un patch en el servidor primary: el primary se retira y un secondary al día pasa a primary. La aplicación puede recibir errores de escritura durante unos segundos.
• Cambiar el tamaño del oplog (replSetResizeOplog) — La ventana del oplog es corta: los secondary quedan 'too stale' tras un mantenimiento, el backup no alcanza el oplog o no basta para una recuperación a un punto en el tiempo. Se amplía en cada miembro sin interrupción.
• Comprobar y completar la Feature Compatibility Version (FCV) — Tras un upgrade, la FCV se quedó en la versión anterior o hay diferencias de versión entre miembros: se comprueban la versión del binario y la FCV de todos los miembros y se sube la FCV a la nueva versión.
• Añadir un shard al cluster (sh.addShard) — La capacidad no basta: se ha montado un nuevo replica set de shard (shardsvr) y se añade al cluster; el balancer mueve los chunks de forma gradual.
• Quitar un shard (removeShard: drain y movePrimary) — Un shard se retira: sus chunks se vacían hacia los demás shards (drain), las bases de datos de las que es primary shard se mueven (movePrimary) y después se elimina del cluster.
• Balancer: ventana horaria, detener / iniciar, desactivar por colección — Las migraciones de chunks generan carga en horas punta, deben detenerse para un mantenimiento/backup o no se quiere equilibrar una colección concreta.
• Distribución desequilibrada o jumbo chunks (diagnóstico y solución) — Un shard está mucho más lleno que los demás, el balancer no mueve datos, hay chunks marcados como 'jumbo' o moveChunk falla: se analizan la distribución, los jumbo chunks y los errores del balancer.
• Cambiar la shard key (reshardCollection) — La shard key actual provoca un shard caliente, jumbo chunks o consultas scatter-gather: la colección se redistribuye en línea con la nueva shard key (5.0+). Al final, las escrituras esperan unos 2 s.

Antes de empezar

• En el servidor de administración está instalado mongosh y hay resolución de nombres y acceso a los puertos …de mongos (…)…de todos los miembros (…)…. Los nombres de la conexión deben coincidir con los nombres de los miembros en rs.conf().
• Dispone de la contraseña del usuario …; su rol es root o al menos clusterAdmin + readAnyDatabase.… Para conectarse directamente al replica set de un shard o del config server se necesita el usuario administrador shard-local (creado en la guía mongo-sharded).…
• Se ha abierto el registro de cambio / la ventana de mantenimiento y se ha informado al equipo de la aplicación. Los reconfig, stepDown y las operaciones de shard pueden provocar unos segundos de elección (election) o de retraso en el enrutamiento.
• El nuevo miembro … se ha preparado con las fases de sistema operativo, instalación, keyfile y configuración de la guía de instalación del replica set: la misma versión de MongoDB (…), el mismo keyfile, replication.replSetName: …, mongod en marcha pero SIN rs.initiate. Hay resolución de nombres y acceso a los puertos en ambos sentidos con los demás miembros; el disco de datos tiene libre al menos el tamaño de los datos actuales.
• Durante el initial sync se reescriben todos los datos en el disco del miembro…; como el directorio antiguo se aparta, hace falta el doble del tamaño de los datos en espacio libre…. Los miembros restantes mantienen la mayoría y la ventana del oplog del miembro de origen es más larga que lo que durará el initial sync.

Fases de la guía

• Estado: miembros, retraso y oplog (solo lectura) — Mostrar el estado y el retraso de los miembros · Mostrar la configuración (priority, votes, hidden, delay) · Interpretar el resultado y elegir el escenario adecuado
• Estado: shards, balancer y distribución de chunks (solo lectura) — Mostrar el resumen del cluster · Distribución de chunks y jumbo chunks · Comprobar el estado de los replica sets de shard
• 1. Diagnóstico: ¿está listo el nuevo miembro? — Comprobar el servicio y la versión del nuevo miembro · Ver el estado del set actual y el tamaño de los datos · Comprobar el acceso al nuevo miembro
• 2. Red de seguridad — Guardar la configuración actual del replica set
• 3. Aplicación: añadir el miembro y esperar a que se sincronice — Añadir el miembro con priority 0 / votes 0 · Esperar a que termine el initial sync · Dar voto y priority al miembro
• 4. Verificación y pasos posteriores — Verificar el estado · Actualizar la cadena de conexión de la aplicación y la supervisión
• 1. Diagnóstico: ¿el miembro que se quita es el primary?, ¿se mantiene la mayoría? — Calcular el rol del miembro y los votos restantes
• 2. Red de seguridad — Guardar la configuración actual del replica set
• 3. Aplicación: quitar el miembro — Quitar el miembro de la configuración (rs.remove) · Detener mongod en el servidor retirado
• 4. Verificación y pasos posteriores — Verificar el estado · Actualizar las cadenas de conexión, la supervisión y el firewall
• 1. Diagnóstico — Ver los ajustes actuales del miembro y la ventana del oplog
• 2. Red de seguridad — Guardar la configuración actual del replica set
• 3. Aplicación — Cambiar el ajuste del miembro (rs.reconfig)
• 4. Verificación — Verificar el resultado
• 1. Diagnóstico: arbiter y nuevo miembro — Ver el arbiter y el write concern · Comprobar que el nuevo miembro está listo
• 2. Red de seguridad — Guardar la configuración actual del replica set
• 3. Aplicación: añadir el miembro con datos y quitar el arbiter — Añadir el nuevo miembro con priority 0 / votes 0 · Esperar a que termine el initial sync · Dar voto y priority al nuevo miembro · Quitar el arbiter · Detener mongod en el servidor del arbiter
• 4. Verificación y pasos posteriores — Verificar el estado y el write concern
• 1. Diagnóstico: ¿hay que resincronizar realmente el miembro? — Ver el estado del miembro y su último mensaje · Ver el error en el log del miembro
• 2. Red de seguridad — Guardar la configuración actual del replica set
• 3. Aplicación: vaciar el directorio de datos e initial sync — Detener mongod · …Apartar…Vaciar… el directorio de datos · Iniciar mongod (empieza el initial sync) · Esperar a que termine el initial sync
• 4. Verificación y pasos posteriores — Verificar el estado · Borrar el directorio de datos antiguo
• 1. Diagnóstico: ¿se ha perdido realmente la mayoría de forma permanente? — Ver el estado y los optime desde un miembro superviviente · Comprobar que los miembros perdidos están apagados
• 2. Red de seguridad — Guardar la configuración del miembro superviviente
• 3. Aplicación: force reconfig — Reconfigurar a la fuerza solo con los miembros restantes · Comprobar que se ha elegido un primary
• 4. Verificación y pasos posteriores — Probar una escritura majority · Volver a añadir los miembros perdidos y eliminar la causa raíz
• 1. Diagnóstico: ¿están al día los secondary? — Ver el primary y los retrasos
• 2. Aplicación — Congelar los demás secondary (para que se elija el miembro destino) · Retirar el primary (rs.stepDown)
• 3. Verificación — Verificar el nuevo estado
• 1. Diagnóstico: tamaño y ventana actuales del oplog — Tamaño y ventana del oplog en cada miembro