ゲームラグ白書 › L12 データベース

DBのフェイルオーバー Database failover

原因ID db-failover · 主担当 インフラチーム・DBインフラ · 副担当 ゲーム開発チーム・サーバー開発

図と実験のあるメインページでこのカードを開く →

プライマリが落ちてスタンバイDBに切り替わる間は書き込みができず、レプリケーションが間に合わなかった最後のデータは失われることがあります。

なぜ プライマリの障害でスタンバイDBが昇格 → すると 切り替え中は数秒〜数分書き込み不可、非同期レプリケーションならレプリカに届いていないデータが失われる可能性 → 画面では 一時的にすべての保存が失敗、アイテム・経験値のロールバック

症状

不発・ロールバック, フリーズ, 切断, 接続不可・無限ロード

要因

ストール, パケットロス

誰に起きるか

サーバー全体

いつ

ときどきランダムに

担当

主担当 インフラチーム・DBインフラ · 副担当 ゲーム開発チーム・サーバー開発

ゲーム開発チームの対応

再試行可能な保存、切れた接続をすぐに捨てて新しいアドレスへ接続し直す設定（コネクションプール・DNSキャッシュ）、フェイルオーバー訓練で再接続を確認。

インフラチームの対応

同期・準同期レプリケーション（書き込み遅延とのトレードオフ）、フェイルオーバー訓練、切り替え時間・レプリケーション遅延の監視。

数値の目安

マネージドDBの自動フェイルオーバーは通常数十秒〜2分。非同期レプリケーションなら、レプリケーション遅延の分（1秒未満〜数秒）だけ直近の保存が失われることがあります。

グラフでは

接続が一斉に切れる · DB接続数、書き込みエラー数

確認箇所

DB側のフェイルオーバーの記録（RDSはイベントRDS-EVENT-0013がフェイルオーバー開始・RDS-EVENT-0049がフェイルオーバー完了、自前で運用するDBは昇格ログ）と、ゲームサーバーのDB接続数・接続エラー数を1つのグラフに並べる。非同期レプリケーションなら、障害直前のレプリケーション遅延（RDSのReplicaLag、PostgreSQLのpg_stat_replicationのreplay_lag）も確認

該当する場合

保存の失敗が1つの区間に集中し、その区間がフェイルオーバーの開始から完了までと重なる。ロールバックされた分が障害直前のレプリケーション遅延とほぼ同じ。切り替え完了後もエラーが続くゲームサーバーは、古いアドレスで確立した接続を使い続けている

該当しない場合

フェイルオーバーの記録がない時刻の接続断は、ネットワークかDBの過負荷側

確認手段

インフラのツールで確認（ゲームコード不要）

実際の事例

Riot Games 2021: League of Legends EUWの5時間障害：補助的なDB一つでサーバー全体が停止

出典

1. Failing over a Multi-AZ DB instance for Amazon RDS AWS
   Multi-AZのフェイルオーバーは通常60〜120秒、フェイルオーバー後は接続を張り直す必要があり、JVMのDNSキャッシュTTLは60秒以下を推奨
2. High availability for Amazon Aurora AWS
   障害中は読み書きが失敗し、通常60秒以内（多くは30秒以内）に復旧
3. Semisynchronous Replication MySQL
   非同期レプリケーションでは、プライマリが落ちるとコミット済みのトランザクションがレプリカにないことがある、準同期はレプリカ1台の受信確認を待つことでこれを減らす代わりに遅延が増える
4. Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
   ログシッピングは非同期のため、プライマリが落ちるとまだ送っていないトランザクションを失う、ストリーミングレプリケーションの遅延は通常1秒未満
5. Amazon RDS event categories and event messages AWS
   RDS-EVENT-0013：Multi-AZフェイルオーバー開始、RDS-EVENT-0049：Multi-AZフェイルオーバー完了
6. Amazon CloudWatch metrics for Amazon RDS AWS
   ReplicaLag：リードレプリカがソースDBより遅れている時間（秒）
7. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
   pg_stat_replicationのreplay_lag：プライマリがWALを書いた後、レプリカが適用を通知するまでにかかった時間

あわせて読みたい原因

同じ層：L12 データベース

• インデックスのないクエリ
• ホットスポットの行ロック競合
• DBのデッドロック
• コネクションプールの枯渇
• レプリケーション遅延
• チェックポイント・ログフラッシュ
• コールドキャッシュ（再起動直後）
• ログイン殺到とN+1クエリ
• 大規模なバッチ処理
• 長い保存間隔による進行状況の消失
• キャッシュスタンピード
• 長時間開いたままのトランザクション
• Redisの遅いコマンド
• 実行計画の変化によるクエリ遅延
• サービス中のスキーマ変更（DDL）によるロック

同じ症状（不発・ロールバック）を起こすほかの層の原因

• 時刻同期の誤差 L1 クライアントのゲームプロセス
• クラウドのNATゲートウェイの接続・ポート上限 L5 データセンターのネットワーク機器
• スイッチのマイクロバースト L5 データセンターのネットワーク機器
• リングバッファ不足 L6 サーバーのネットワークカード
• クラウドのPPS上限超過 L6 サーバーのネットワークカード
• OOM Killer L7 サーバーOS（カーネル）
• システム時刻のジャンプ（NTPステップ） L7 サーバーOS（カーネル）
• サーバー間接続のエフェメラルポート枯渇 L7 サーバーOS（カーネル）

図と実験のあるメインページでこのカードを見る