DBAtlas · Atlas de operaciones de bases de datos

Retraso de replicación / replicación detenida

Síntoma

El standby/réplica se está quedando atrás o se ha detenido por completo; las réplicas de lectura muestran datos obsoletos.

1. ¿Qué tan grande es el lag y está creciendo o es estable?

¿Cuál es el lag en segundos/bytes? ¿Es un desfase estable o crece continuamente? Si crece, la réplica no puede seguir el ritmo del apply; si es estable, hubo una detención momentánea.

Oracle

SELECT name, value, unit FROM v$dataguard_stats WHERE name LIKE '%lag%';

PostgreSQL

SELECT client_addr, state, write_lag, flush_lag, replay_lag FROM pg_stat_replication;

MySQL

SHOW REPLICA STATUS\G  -- Seconds_Behind_Source

SQL Server

SELECT ar.replica_server_name, drs.redo_queue_size, drs.log_send_queue_size FROM sys.dm_hadr_database_replica_states drs JOIN sys.availability_replicas ar ON drs.replica_id=ar.replica_id;

Redis

INFO replication  # master_repl_offset vs slave offset

2. ¿Está funcionando la replicación? ¿Hay errores?

¿Cuál es el estado del hilo IO/SQL, del proceso de apply? ¿Se cortó la conexión? Si hay un error (p. ej., fila en conflicto, tabla faltante), el apply se ha detenido; lea el mensaje de error.

MySQL

SHOW REPLICA STATUS\G  -- Replica_IO_Running / Replica_SQL_Running / Last_Error

PostgreSQL

SELECT status, last_msg_receipt_time, latest_end_lsn FROM pg_stat_wal_receiver;  -- on the standby

Oracle

SELECT process, status, sequence#, thread# FROM v$managed_standby WHERE process LIKE 'MRP%' OR process LIKE 'RFS%';

3. Encuentre el cuello de botella

¿Por qué no puede seguir el ritmo? ¿Apply de un solo hilo más una carga de escritura intensa (PG/MySQL aplican mayormente en serie), un cuello de botella de I/O en el standby, la red o una consulta larga que bloquea el apply (PG hot_standby_feedback / recovery conflict)?

4. Reduzca el lag a cero

Acelere el apply: habilite el apply paralelo (MySQL replica_parallel_workers; slave_parallel_workers antes de 8.0.26; PG no lo tiene, pero hay parámetros de recovery), mejore el I/O del standby, resuelva la consulta que bloquea el apply. Si se detuvo con un error: corrija el error (resuelva manualmente la fila en conflicto) y reanude la replicación.

5. Reconstruya si está roto

Si la réplica está muy atrasada/rota, lo más limpio es resincronizar: reconstruya el standby a partir de un backup reciente (PG pg_basebackup, MySQL clone/xtrabackup, Oracle RMAN duplicate). Crítico: encuentre la causa antes de reconstruir, o volverá a ocurrir.

Abrir en DBAtlas →