Solución de Problemas de Retraso en la Replicación de MongoDB: Causas y Soluciones

El retraso en la replicación de MongoDB generalmente comienza como una pequeña molestia operativa. Un gráfico comienza a subir. Un secundario se retrasa 15 segundos, luego 2 minutos. Alguien pregunta si las lecturas están obsoletas. Alguien más sugiere reiniciar el nodo. Antes de hacer eso, tómese un momento y averigüe qué parte de la replicación está perdiendo terreno.

Los secundarios de MongoDB copian las operaciones del oplog del primario y las aplican localmente. El retraso en la replicación significa que un secundario no ha aplicado operaciones tan recientemente como el primario. Esto puede afectar las lecturas secundarias, las copias de seguridad tomadas de secundarios, los trabajos de análisis y la conmutación por error. También puede ocultar un riesgo mayor: si el secundario se retrasa más allá de la ventana del oplog, es posible que no pueda ponerse al día desde el oplog en absoluto.

La ruta de solución de problemas más rápida es responder tres preguntas:

• ¿Está retrasado cada secundario, o solo uno?
• ¿El retraso es temporal, constante o creciente?
• ¿El secundario aún está dentro de la ventana del oplog?

Esas respuestas deciden qué hacer a continuación.

Mida el Retraso Sin Adivinar

Comience en mongosh:

rs.status()

Encuentre el primario y compare su optimeDate con el optimeDate de cada secundario. También busque miembros no saludables, mensajes de latido y miembros atascados en estados como RECOVERING o STARTUP2.

Para un resumen más amigable, ejecute:

rs.printSecondaryReplicationInfo()

Algunos materiales antiguos usan rs.printSlaveReplicationInfo(). Si mantiene sistemas antiguos, es posible que aún vea ese ayudante. La redacción moderna es "secondary".

Luego verifique la ventana del oplog:

rs.printReplicationInfo()

La ventana del oplog es la cantidad de historial actualmente retenido en el oplog. Si su secundario está 40 minutos atrasado y la ventana del oplog es de varios días, tiene margen para solucionar problemas. Si su secundario está 40 minutos atrasado y la ventana del oplog es de 1 hora durante el tráfico pico, está cerca de una situación de reconstrucción.

No confíe únicamente en valores de estilo SecondsBehind de una sola herramienta. La desviación del reloj, los miembros retrasados y los breves picos pueden hacer que un número sea engañoso. Compare la salida de estado con los gráficos de monitoreo del volumen de escritura, la latencia del disco, la CPU y el rendimiento de la red.

Si Todos los Secundarios Están Retrasados

Cuando todos los secundarios se retrasan aproximadamente al mismo tiempo, la causa suele ser anterior a cualquier secundario. Primero, observe la carga de trabajo de escritura del primario.

Los desencadenantes comunes incluyen:

• Importaciones masivas o rellenos.
• Operaciones grandes de updateMany o deleteMany.
• Limpieza TTL después de un período de acumulación.
• Implementaciones de aplicaciones que cambiaron el volumen de escritura.
• Construcciones de índices o mantenimiento de esquemas.
• Un aumento repentino en escrituras pequeñas que crean muchas entradas de oplog.

Pregunte qué cambió al mismo tiempo que comenzó el retraso. Un pico que comienza exactamente cuando comienza un trabajo nocturno rara vez es un misterio de MongoDB.

En el primario, inspeccione las operaciones activas:

db.currentOp({ active: true })

Si encuentra un trabajo por lotes, considere limitarlo en lugar de dejar que termine a máxima velocidad. Por ejemplo, procese documentos en rangos de _id, duerma entre lotes y observe el retraso. Esto es especialmente útil para trabajos de limpieza donde terminar en 30 minutos es menos importante que mantener saludable el conjunto de réplicas.

Si el volumen de escritura sostenido es simplemente mayor de lo que el conjunto de réplicas puede manejar, necesita un cambio de capacidad o arquitectura. Mejores discos, más CPU, una clase de instancia diferente, optimización de la ruta de escritura o fragmentación pueden ser la respuesta correcta. Cambiar la preferencia de lectura no solucionará un primario que está produciendo más trabajo del que el conjunto puede aplicar.

Si Solo Un Secundario Está Retrasado

Un secundario retrasado generalmente apunta a un problema local. Inicie sesión en ese host y verifique los conceptos básicos:

iostat -xz 1
vmstat 1
top

Dentro de MongoDB, use:

mongostat --host secondary.example.com:27017
mongotop --host secondary.example.com:27017

El disco es un culpable común. Un secundario que usa almacenamiento más lento que el primario puede estar bien durante el tráfico normal y luego retrasarse durante los picos. Los volúmenes en la nube también pueden alcanzar los límites de rendimiento o IOPS. Busque alta utilización, altos tiempos de espera y colas.

La CPU puede importar cuando la carga de trabajo incluye muchas actualizaciones, compresión, cifrado o tráfico de consultas pesado en el mismo miembro. La presión de la memoria importa cuando el secundario no puede mantener los datos activos y los índices en caché mientras aplica escrituras.

También verifique qué más se ejecuta en el host. Las copias de seguridad, los análisis antivirus, las instantáneas del sistema de archivos, la compresión de registros y las consultas de informes pueden competir con la replicación. Si el nodo retrasado es también el "lugar seguro" donde todos ejecutan análisis ad-hoc, probablemente haya encontrado el problema.

Las Lecturas en Secundarios Pueden Crear Retraso

Las lecturas secundarias no son gratuitas. Usan el mismo caché, CPU y disco que necesita la replicación. Una sola agregación que escanea una colección grande puede ser suficiente para hacer que un secundario se retrase durante un período ocupado.

Busque lecturas de larga duración:

db.currentOp({ active: true })

Si la aplicación envía lecturas a secundarios, revise la preferencia de lectura. secondary puede forzar lecturas a miembros retrasados. secondaryPreferred aún puede devolver datos obsoletos. Para flujos de usuario que deben leer sus propias escrituras, use el primario. Para lecturas eventualmente consistentes, configure maxStalenessSeconds para que el controlador evite secundarios que están demasiado atrasados.

Para cargas de trabajo de informes, considere un secundario oculto o una canalización de análisis separada. Los miembros ocultos aún pueden replicarse, pero los controladores no los elegirán para lecturas normales. Eso los convierte en un mejor lugar para copias de seguridad o trabajos de informes controlados, siempre que los dimensione adecuadamente.

El Tamaño del Oplog es un Margen de Recuperación, No una Solución de Velocidad

Un oplog demasiado pequeño generalmente no causa retraso por sí mismo. Hace que el retraso sea peligroso. Si un secundario se retrasa y las entradas de oplog necesarias se sobrescriben, no puede ponerse al día normalmente.

Su ventana de oplog debe ser más larga que sus escenarios realistas de interrupción y mantenimiento. Si un secundario puede estar fuera de línea durante 6 horas durante el parcheo, una ventana de oplog de 4 horas no es suficiente. Si una importación trimestral quema el oplog en unas pocas horas, dimensione para esa carga de trabajo o cambie la forma en que se ejecuta la importación.

En versiones compatibles, redimensione con replSetResizeOplog en cada miembro que necesite un oplog más grande:

use admin
db.adminCommand({ replSetResizeOplog: 1, size: 20480 })

Ese ejemplo solicita aproximadamente 20 GB. En plataformas administradas, use el método de configuración administrada. Evite los consejos antiguos que eliminan y recrean el oplog a menos que esté siguiendo un procedimiento de recuperación cuidadosamente probado.

Después de aumentar el oplog, continúe solucionando el retraso subyacente. Un oplog más grande le da más tiempo; no elimina la saturación del disco, los límites de la red o los picos de escritura excesivos.

Verificaciones de Red Que Realmente Ayudan

Es más probable que los problemas de red afecten a un secundario remoto, una zona de disponibilidad o una ruta de centro de datos. Comience simple:

ping primary.example.com
traceroute primary.example.com

Luego mire más allá de la latencia. La replicación necesita un rendimiento confiable. La pérdida de paquetes, la inspección del firewall, los límites de VPN, los límites de ancho de banda entre regiones o las interfaces de red sobrecargadas pueden crear retraso incluso cuando el ping parece aceptable.

Si solo el miembro entre regiones se retrasa, compárelo con un secundario local bajo la misma carga de escritura. Es posible que necesite una topología diferente, un enlace más grande o una expectativa más clara de que los miembros remotos son para recuperación ante desastres en lugar de lecturas frescas.

Deriva de Datos e Índices

Los miembros del conjunto de réplicas deben tener los mismos índices. Si no es así, la aplicación del oplog puede ralentizarse o fallar. Esto generalmente proviene de cambios manuales, mantenimiento fallido o un miembro restaurado de una fuente inconsistente.

Compare los índices en colecciones activas:

db.orders.getIndexes()

Ejecútelo en el primario y en el secundario retrasado. Si las definiciones difieren, corrija la deriva deliberadamente. Reconstruir un índice grande puede agregar más carga, así que programelo cuidadosamente o reconstruya el miembro desde una fuente limpia si las diferencias están generalizadas.

La divergencia de datos es más grave. Si los errores de replicación muestran registros faltantes o claves duplicadas, el retraso ya no es el único problema. Debe inspeccionar el error, comparar los datos y decidir si una reparación a nivel de tabla, una resincronización o una reconstrucción completa es el camino más seguro.

Sea Conservador con los Reinicios y la Sincronización Inicial

Reiniciar un secundario retrasado a veces ayuda si el proceso está atascado detrás de un problema transitorio. No es una solución universal. Si el miembro está cerca del borde de la ventana del oplog, un reinicio puede costar suficiente tiempo como para llevarlo a un estado irrecuperable.

Antes de reiniciar, verifique:

• Retraso actual.
• Ventana de oplog actual.
• Si el miembro está sincronizando.
• Si existen otros secundarios saludables.
• Si el conjunto de réplicas puede tolerar que el miembro esté inactivo.

La sincronización inicial es la respuesta limpia cuando un secundario no puede ponerse al día o sus datos no son confiables. También es pesada. Copia datos, construye índices y consume recursos de otro miembro. Reconstruya un miembro a la vez, y asegúrese de que su configuración de votación aún admita elecciones seguras mientras el nodo se está reconstruyendo.

Cuándo No Debe Apresurarse a Arreglarlo

Se espera algo de retraso durante el trabajo controlado. Si está ejecutando un relleno planificado, restaurando un secundario o importando datos históricos, la pregunta útil es si el secundario se está poniendo al día a un ritmo aceptable. Un gráfico de retraso que sube durante 20 minutos y luego baja constantemente puede no necesitar intervención. Un gráfico de retraso que sube todos los días y nunca regresa a la línea de base sí.

Esta distinción es importante porque algunas soluciones son disruptivas. Matar un trabajo por lotes puede dejar los datos de la aplicación a medio actualizar. Reiniciar un secundario puede costar calor de caché y hacer que la recuperación sea más lenta. Reconstruir un miembro puede consumir más red y disco que simplemente dejar que aplique el trabajo pendiente.

Para trabajos planificados, establezca un presupuesto de retraso antes de que comience el trabajo. Por ejemplo, podría decidir que un relleno de mantenimiento puede crear hasta 10 minutos de retraso en un secundario de informes, pero no en un candidato a conmutación por error. Observe el retraso, la ventana del oplog y la tasa de escritura mientras se ejecuta el trabajo. Si el trabajo se acerca al presupuesto, póngalo en pausa o reduzca el tamaño del lote.

También ayuda separar las réplicas orientadas al usuario de las réplicas de mantenimiento. Un secundario utilizado para lecturas de aplicaciones debe tener una tolerancia de retraso más estricta que un miembro oculto utilizado para copias de seguridad. Si cada secundario tiene un trabajo diferente, los umbrales de alerta deben reflejar esos trabajos en lugar de usar un número para todo el conjunto.

Qué Registrar Durante un Incidente

Los incidentes de replicación son mucho más fáciles de entender después si guarda la evidencia correcta. Antes de cambiar la configuración, capture:

rs.status()
rs.conf()
rs.printReplicationInfo()
rs.printSecondaryReplicationInfo()

También guarde las métricas a nivel de host del primario y del secundario retrasado: latencia del disco, CPU, memoria y rendimiento de la red. Si se estaba ejecutando un trabajo por lotes o una implementación, registre su hora de inicio y el comando o la versión de lanzamiento.

Esto no es papeleo por sí mismo. Sin una línea de tiempo, el próximo incidente comienza desde cero. Con una línea de tiempo, puede notar que el retraso siempre sigue a una exportación, copia de seguridad o tarea de limpieza específica. Eso convierte un vago problema de base de datos en un problema de capacidad programable.

Un Mapa de Soluciones Prácticas

Use el síntoma para elegir el próximo movimiento:

Síntoma	Área probable	Próxima acción
Todos los secundarios se retrasan durante un trabajo por lotes	Ráfaga de escritura	Limite o divida el trabajo
Un secundario siempre se retrasa	Problema de recurso local	Verifique disco, CPU, memoria y lecturas locales
El retraso crece solo en el miembro remoto	Red/topología	Verifique rendimiento, pérdida de paquetes y diseño entre regiones
El retraso está cerca de la ventana del oplog	Riesgo de recuperación	Aumente el oplog y reduzca la fuente de retraso
El secundario sirve lecturas obsoletas	Preferencia de lectura	Use el primario para lecturas frescas o configure maxStalenessSeconds
El miembro no puede ponerse al día después del tiempo de inactividad	Historial de oplog faltante	Reconstruya desde una copia de seguridad o sincronización inicial

La buena solución de problemas de replicación de MongoDB es principalmente observación disciplinada. Encuentre si el primario está produciendo demasiado trabajo, el secundario está aplicando demasiado lento o el enlace entre ellos está restringido. Luego cambie lo que realmente está limitando la replicación en lugar de aplicar un reinicio, resincronización o ajuste de configuración genérico.