ゲームラグ白書 › L12 データベース
レプリケーション遅延 Replication lag
原因ID db-replica-lag · 主担当 インフラチーム・DBインフラ · 副担当 ゲーム開発チーム・サーバー開発
図と実験のあるメインページでこのカードを開く →
書き込みはプライマリに、読み込みはレプリカから行う構成で、レプリカの追従が遅れると、書いたばかりの内容が見えません。
なぜ プライマリに書き込みが集中し、レプリカが数秒遅れる → すると 保存したばかりの内容をレプリカから読むと、まだ反映されていない → 画面では 買ったばかりのアイテムが表示されない、取引所の価格が古い値のまま、重複付与のバグ
- 症状
- 不発・ロールバック
- 要因
- 遅延
- 誰に起きるか
- 特定の機能だけ
- いつ
- 人が集中したとき, 夜のピーク時間帯
- 担当
- 主担当 インフラチーム・DBインフラ · 副担当 ゲーム開発チーム・サーバー開発
- ゲーム開発チームの対応
- 書いたばかりのデータはプライマリから読む、付与済みかどうかの確認と付与はプライマリで1つのトランザクションに（ユニークキーや条件付きUPDATEで重複を防止）。
- インフラチームの対応
- レプリケーション遅延のアラート、レプリカのスペックをプライマリ以上にして並列レプリケーションを適用、大量削除は細かく分けて実行、レプリカで長時間動く集計クエリの管理。
- グラフでは
- 人数・負荷に連動して上昇 · レプリケーション遅延（秒）
- 確認箇所
- MySQLはレプリカでSHOW REPLICA STATUSのSeconds_Behind_Source（8.0.22より前のバージョンはSHOW SLAVE STATUS）を確認。PostgreSQLはプライマリのpg_stat_replicationのwrite_lag・flush_lag・replay_lag、RDSはReplicaLagを確認
- 該当する場合
- 「表示されない」という報告の時刻に遅延が数秒以上あり、遅延が解消した後に見直すと正常。書き込みの殺到や大量削除、レプリカの長い集計クエリの時刻に遅延が大きくなる
- 該当しない場合
- 遅延が0付近なのに表示されないなら、ゲームサーバーのキャッシュや同期側
- 確認手段
- インフラのツールで確認（ゲームコード不要）
- もっと詳しく
- 書き込みが多くなくても遅れることがあります。プライマリで10分かかった大量削除が1つあると、レプリカでも再実行される間、その分だけ遅れます。レプリカで長時間動く集計クエリも追従を遅らせます。
出典
- SHOW REPLICA STATUS Statement MySQL
Seconds_Behind_Source：レプリカが現在適用中のイベントがプライマリで記録された時刻との差（レプリケーション遅延） - Replica Server Options and Variables MySQL
replica_parallel_workersで複数のスレッドがトランザクションを並列に適用（デフォルトは4。0なら1つのスレッドが順番に適用） - Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
ストリーミングレプリケーションはデフォルトで非同期のため、コミットからレプリカへの反映までに遅延がある（レプリカが追従できていれば通常1秒未満） - MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement MySQL
8.0.22からSHOW SLAVE STATUSの代わりにSHOW REPLICA STATUS、それより前のバージョンはSHOW SLAVE STATUS - The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_replicationのwrite_lag・flush_lag・replay_lag：プライマリがWALを書いた後、レプリカが書き込み・ディスクへのフラッシュ・適用を通知するまでにかかった時間 - Amazon CloudWatch metrics for Amazon RDS AWS
ReplicaLag：リードレプリカがソースDBより遅れている時間（秒）
あわせて読みたい原因
同じ層：L12 データベース
同じ症状（不発・ロールバック）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る