レプリケーションの遅延 / 停止

症状

スタンバイ/レプリカが遅延している、または完全に停止している。読み取りレプリカが古いデータを表示している。

1. ラグの大きさと、増加中か一定か

ラグは秒/バイトでどれだけか。一定のずれか、継続的に増加しているか。増加しているならレプリカは適用に追いつけておらず、一定なら一時的な停滞があった。

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. レプリケーションは動作しているか、エラーはあるか

IO/SQL スレッドの状態、適用プロセスはどうか。接続が切れていないか。エラー (例: 競合する行、存在しないテーブル) があれば適用は停止している。エラーメッセージを読む。

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. ボトルネックを見つける

なぜ追いつけないのか。シングルスレッドの適用と重い書き込み負荷 (PG/MySQL は主に直列に適用する)、スタンバイの I/O ボトルネック、ネットワーク、あるいは適用をブロックする長いクエリ (PG hot_standby_feedback / リカバリ競合) か。

4. ラグを解消する

適用を高速化する: 並列適用を有効にし (MySQL replica_parallel_workers — 8.0.26 より前は slave_parallel_workers。PG にはないがリカバリ設定がある)、スタンバイの I/O を改善し、適用をブロックするクエリを解消する。エラーで停止した場合: エラーを修正し (競合する行を手動で解決)、レプリケーションを再開する。

5. 壊れている場合は再構築する

レプリカが大きく遅延している/壊れている場合は、再同期が最もクリーンである: 新しいバックアップからスタンバイを再構築する (PG pg_basebackup、MySQL clone/xtrabackup、Oracle RMAN duplicate)。重要: 再構築の前に原因を特定すること。さもなければ再発する。