DBAtlas · Atlas d'exploitation des bases de données

Retard de réplication / réplication arrêtée

Symptôme

La standby/le réplica prend du retard ou s'est complètement arrêté ; les réplicas en lecture affichent des données obsolètes.

1. Quelle est l'ampleur du retard, et augmente-t-il ou est-il stable

Quel est le retard en secondes/octets ? Est-ce un décalage stable ou en croissance continue ? S'il croît, le réplica ne suit pas l'application ; s'il est stable, il y a eu un blocage momentané.

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. La réplication fonctionne-t-elle, y a-t-il des erreurs

Quel est l'état des threads IO/SQL, du processus d'application, la connexion est-elle rompue ? En cas d'erreur (par ex. ligne en conflit, table manquante), l'application s'est arrêtée ; lisez le message d'erreur.

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. Trouvez le goulet d'étranglement

Pourquoi ne suit-il pas ? Application mono-thread avec une forte charge d'écriture (PG/MySQL appliquent surtout en série), goulet E/S sur la standby, réseau, ou requête longue bloquant l'application (PG hot_standby_feedback / recovery conflict) ?

4. Résorbez le retard

Accélérez l'application : activez l'application parallèle (MySQL replica_parallel_workers, slave_parallel_workers avant 8.0.26 ; PG n'en a pas, mais il existe des paramètres de recovery), améliorez les E/S de la standby, résolvez la requête qui bloque l'application. Si elle s'est arrêtée sur une erreur : corrigez l'erreur (résolvez manuellement la ligne en conflit) et relancez la réplication.

5. Reconstruisez si elle est cassée

Si le réplica est très en retard/cassé, le plus propre est de resynchroniser : reconstruisez la standby à partir d'une sauvegarde récente (PG pg_basebackup, MySQL clone/xtrabackup, Oracle RMAN duplicate). Essentiel : trouvez la cause avant de reconstruire, sinon cela se reproduira.

Ouvrir dans DBAtlas →