Solución de problemas de retraso en la replicación

Latencia de la red

El retraso en la replicación puede acumularse cuando los nodos del clúster no pueden comunicarse entre sí de forma fiable.

Verifique las rutas de red entre los miembros de su conjunto de réplicas para asegurarse de que no haya pérdida de paquetes ni problemas de enrutamiento de red.

Utilice herramientas como para probar la latencia entre los miembros del conjunto ping y traceroute para exponer el enrutamiento de paquetes entre los puntos finales de la red.

Como alternativa, ejecute y examine replSetGetStatus el pingMs campo. Esto devuelve la latencia actual de la red en milisegundos entre los nodos primario y secundario.

Agotamiento de recursos secundarios

Los nodos secundarios pueden experimentar contención de recursos cuando no pueden gestionar eficientemente las operaciones de lectura entrantes del nodo primario. Esto puede provocar problemas de memoria, como la contención de caché. Cuando la caché alcanza umbrales críticos, el servidor utiliza subprocesos de la aplicación para eliminar páginas, lo que reduce el número de subprocesos disponibles para gestionar la replicación.

Para comprobar si el servidor redirige los subprocesos de la aplicación a tareas de desalojo, ejecute el siguiente comando en su shell mongosh:

db.serverStatus().wiredTiger.cache['pages evicted by application threads']

• Si Resultado 0 =: No se pausan subprocesos de la aplicación para su desalojo.

• Si Result > 0 (y sigue aumentando): La base de datos está bajo presión de caché. Las consultas entrantes deben eliminar los datos almacenados en caché antes de ejecutarse, lo que puede aumentar el retraso de replicación.

Los usuarios de Atlas también pueden monitorear las métricas WiredTiger Cache Activity y Page Faults para investigar problemas relacionados con la caché.

Para conocer posibles estrategias para solucionar este problema,consulte la sección "Amplíe sus recursos".

Problemas relacionados con el disco

Si un nodo secundario no puede escribir los datos modificados en el disco con la suficiente rapidez, se queda rezagado con respecto al nodo principal. Este fenómeno ocurre cuando el volumen de escrituras provenientes del nodo principal supera la velocidad de escritura del disco del nodo secundario.

Los problemas relacionados con el disco son frecuentes en los sistemas multiusuario, incluidas las instancias virtualizadas, y pueden ser transitorios si el sistema accede a los dispositivos de disco a través de una red IP.

Para evaluar el estado del disco, utilice herramientas a nivel del sistema, como iostat o vmstat.

Los usuarios de Atlas pueden acceder a métricas de Atlas como Disk IOPS y Disk Space Used para investigar problemas de disco.

Algunas causas comunes de problemas de disco incluyen:

• Aprovisionamiento insuficiente: El servidor secundario tiene discos más lentos o un menor rendimiento de IOPS que el servidor principal.

• Sobrecarga de virtualización: En entornos compartidos, otras máquinas virtuales pueden saturar el controlador del disco físico.

Algunas posibles soluciones a los problemas de disco incluyen:

• Incremento de las IOPS aprovisionadas

• Actualización a almacenamiento NVMe

• Actualización a un nivel superior del clúster Atlas. Para obtener más información, consulte Dimensionamiento del clúster Atlas y selección de nivel.

Operaciones de larga duración

En algunos casos, las operaciones de larga duración en el primario pueden bloquear la replicación en los secundarios. Para obtener los mejores resultados, configura el nivel de confirmación de escritura (write concern) para que solicite la confirmación de la replicación a los secundarios. Esto impide que se devuelvan las operaciones de escritura si la replicación no puede seguir el ritmo de la carga de escritura.

También puede utilizar el analizador de rendimiento de la base de datos para identificar consultas lentas u operaciones de larga duración que se correlacionen con el retraso observado.

Carga de escritura excesiva

Las operaciones de escritura masiva pueden exceder la capacidad de los conjuntos de réplicas para replicarse de manera oportuna, lo que provoca retrasos en la replicación.

Las siguientes subsecciones ofrecen posibles soluciones a este problema:

db.collName.deleteMany({createdDate: {$gte: new Date("2018-12-01"), $lt: new Date("2019-01-01")}});
db.collName.deleteMany({createdDate: {$gte: new Date("2018-11-01"), $lt: new Date("2018-12-01")}});
db.collName.deleteMany({createdDate: {$gte: new Date("2018-10-01"), $lt: new Date("2018-11-01")}});

db.collection.createIndex({ status: 1 });

db.collection.deleteMany({ status: "inactive" });

Tamaño de la ventana de oplog

Si la ventana del oplog es demasiado pequeña para la cantidad de datos que se sincronizan, es posible que se produzca un retraso en la replicación. Un oplog más grande puede proporcionar al conjunto de réplicas una mayor tolerancia al retraso.

Para comprobar el tamaño del oplog y los rangos de fechas de sus operaciones para un miembro del conjunto de réplicas determinado, conéctese al miembro en mongosh y ejecute el rs.printReplicationInfo() método. El oplog debe ser lo suficientemente largo como para almacenar todas las transacciones durante el tiempo de inactividad más largo que espere en unservidor secundario.1 [] Como mínimo, un oplog debe poder almacenar un mínimo 24 de horas de operaciones; sin embargo, muchos usuarios prefieren tener 72 horas o incluso una semana de trabajo de operaciones.

Para cambiar el tamaño del oplog, consulta el tutorial Cambia el tamaño del oplog de los nodos del set de réplicas autogestionado.