ID de la causa db-replica-lag · Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si se escribe en la BD principal y se lee de una réplica, cuando la réplica va con retraso no se ve lo que se acaba de escribir.
Por qué Las escrituras se concentran en la BD principal y la réplica se queda varios segundos atrás → Efecto Al leer de la réplica lo que se acaba de guardar, todavía no está → En pantalla El objeto recién comprado no aparece, el mercado muestra precios antiguos, bugs de entregas duplicadas
Cuando se junta mucha gente, Horas pico de la noche
Responsable
Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Leer de la BD principal los datos recién escritos, comprobar y hacer la entrega en una sola transacción en la BD principal (bloquear duplicados con una clave única o un UPDATE condicional).
Tareas (Equipo de infraestructura)
Configurar alertas de retraso de replicación, dar a las réplicas un tamaño igual o mayor que el de la BD principal y activar la replicación en paralelo, ejecutar los borrados masivos en tandas pequeñas, controlar las consultas de agregación largas en las réplicas.
En el gráfico
Sube con la carga · Retraso de replicación (segundos)
Dónde mirar
En MySQL, Seconds_Behind_Source de SHOW REPLICA STATUS en la réplica (SHOW SLAVE STATUS en versiones anteriores a 8.0.22). En PostgreSQL, write_lag, flush_lag y replay_lag de pg_stat_replication en el servidor principal; en RDS, ReplicaLag
Se confirma si
A la hora de los reportes de “no aparece”, el retraso es de varios segundos o más, y al volver a mirar cuando se recupera, todo está bien. El retraso crece con las avalanchas de escrituras, los borrados masivos o las consultas de agregación largas en la réplica
Se descarta si
Si el retraso está cerca de 0 y aun así no aparece, apunta a la caché o a la sincronización del servidor del juego
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Puede quedarse atrás aunque no haya muchas escrituras. Un único borrado masivo que tardó 10 minutos en la BD principal vuelve a ejecutarse en la réplica y la retrasa ese mismo tiempo, y las consultas de agregación largas en la réplica también le impiden ponerse al día.
Fuentes
SHOW REPLICA STATUS StatementMySQL Seconds_Behind_Source: diferencia respecto a la hora en que se registró en la BD principal el evento que la réplica está aplicando ahora (retraso de replicación)
Replica Server Options and VariablesMySQL replica_parallel_workers: varios hilos aplican transacciones en paralelo (4 por defecto; con 0, un solo hilo en orden)
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL La replicación en streaming es asíncrona por defecto, así que hay un retraso entre el commit y su aplicación en la réplica (normalmente menos de 1 s si la réplica puede seguir el ritmo)
The Cumulative Statistics System (PostgreSQL Documentation)PostgreSQL write_lag, flush_lag y replay_lag de pg_stat_replication: tiempo desde que el servidor principal escribe el WAL hasta que la réplica avisa de que lo escribió, lo pasó a disco y lo aplicó