Solucionar problemas de atraso de la replicación

Latencia de la red

El atraso de la replicación puede aumentar cuando los nodos del clúster no pueden comunicarse de manera confiable entre sí.

Verifica las rutas de red entre los nodos de tu conjunto de réplicas para asegurarte de que no haya pérdida de paquetes o problemas de enrutamiento de red.

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

Alternativamente, ejecuta replSetGetStatus y examina el campo pingMs. Esto devuelve la latencia de red actual en milisegundos entre los nodos primarios y secundarios.

Agotamiento de recursos secundarios

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

Para ver si el servidor redirige los subprocesos de la aplicación a tareas de expulsión, ejecuta el siguiente comando en tu mongosh shell:

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

• Si Resultado = 0: No se han pausado subprocesos de aplicación para desalojo.

• Si Resultado > 0 (y aumentando): la base de datos está sometida a presión de caché. Las consultas entrantes deben eliminar los datos almacenados en caché antes de que se ejecuten, lo que puede aumentar el atraso de la replicación.

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

Para conocer estrategias potenciales para solucionar este inconveniente, consulte Amplía tus recursos .

Problemas relacionados con el disco

Si un nodo secundario no puede vaciar los datos pendientes en el disco lo suficientemente rápido, se retrasa respecto al primario. Este fenómeno ocurre cuando el volumen de escrituras que provienen del primario supera la velocidad de escritura del disco del secundario.

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

Para evaluar el estado del disco, utiliza herramientas a nivel de 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 discos.

Algunas causas comunes de problemas de disco incluyen:

• Subaprovisionamiento: el secundario tiene discos más lentos o menor cantidad de IOPS que el primario.

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

Algunas posibles soluciones a los problemas de disco incluyen:

• Aumentar las IOPSaprovisionadas

• Actualizando a almacenamiento NVMe

• Actualizar a un nivel de clúster Atlas superior. Para obtener más información, consulte Tamaño de 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 perfilador de bases de datos para identificar consultas lentas u operaciones de larga duración que estén relacionadas con las demoras observadas.

Carga Excesiva de Escritura

Las operaciones de escritura masiva pueden superar la capacidad de los sets de réplicas para replicarse de manera oportuna, lo que provoca un atraso de la replicación.

Las siguientes subsecciones ofrecen posibles soluciones a este inconveniente:

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" });

oplog Window Size

Si tu oplog window es demasiado pequeña para la cantidad de datos que estás sincronizando, podrías experimentar un atraso de la replicación. Una oplog más grande puede ofrecer a un set de réplicas una mayor tolerancia a la latencia.

Para comprobar el tamaño del oplog y los intervalos de fecha de sus operaciones para un miembro determinado del conjunto de réplicas, conéctate al miembro en mongosh y ejecuta el método rs.printReplicationInfo(). El oplog debe ser lo suficientemente largo como para contener todas las transacciones durante el tiempo de inactividad más prolongado que se espere en un secundario. [1] Como mínimo, un oplog debería poder contener al menos 24 horas de operaciones; sin embargo, muchos usuarios prefieren tener 72 horas o incluso una semana 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.