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_SourceSQL 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 offset2. ¿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_ErrorPostgreSQL
SELECT status, last_msg_receipt_time, latest_end_lsn FROM pg_stat_wal_receiver; -- on the standbyOracle
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.