遊戲 Lag 白皮書 › L12 資料庫
DB 容錯移轉 Database failover
原因 ID db-failover · 主要負責 基礎設施團隊（DB 基礎設施） · 協同 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
主 DB 故障、切換到備援 DB 的期間無法寫入，最後一批還沒複寫過去的資料可能會遺失。
為什麼 主 DB 故障，備援 DB 升格為主 DB → 於是 切換期間有數秒～幾分鐘無法寫入；若是非同步複寫，尚未複寫的資料可能遺失 → 畫面上 短時間內所有存檔失敗，道具、經驗值回檔
- 症狀
- 吃指令／回檔, 定格, 斷線, 連不上／無限讀取
- 因素
- 停滯, 遺失
- 誰會遇到
- 整個伺服器
- 何時
- 偶爾隨機發生
- 負責單位
- 主要負責 基礎設施團隊（DB 基礎設施） · 協同 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 讓存檔可以重試；設定連線池與 DNS 快取，快速捨棄已中斷的連線並以新位址重新建立連線；在容錯移轉演練時確認能重新連線。
- 基礎設施團隊要做的事
- 採用同步或半同步複寫（代價是寫入延遲增加）、進行容錯移轉演練、監控切換時間與複寫延遲。
- 數值參考
- 受管 DB 的自動容錯移轉通常需要數十秒～2 分鐘。若是非同步複寫，可能會遺失相當於複寫延遲（不到 1 秒～數秒）的最近存檔。
- 圖表上
- 連線同時大量中斷 · DB 連線數、寫入錯誤數
- 查看位置
- 把 DB 端的容錯移轉紀錄（RDS 為事件 RDS-EVENT-0013 開始切換、RDS-EVENT-0049 切換完成，自行維運的 DB 為升格 log）與遊戲伺服器的 DB 連線數、連線錯誤數放在同一張圖表上。若是非同步複寫，也要看故障前一刻的複寫延遲（RDS ReplicaLag、PostgreSQL pg_stat_replication 的 replay_lag）
- 符合的跡象
- 存檔失敗集中在一段期間，且與容錯移轉開始到完成之間重疊。回檔的量與故障前一刻的複寫延遲相近。切換結束後仍持續出錯的遊戲伺服器，是還在使用連到舊位址的連線
- 不符合的跡象
- 沒有容錯移轉紀錄的時間發生的連線中斷，是網路或 DB 過載的問題
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 實際案例
- Riot Games 2021: League of Legends EUW 5 小時事故：一個附屬 DB 讓整個伺服器停擺
出處
- Failing over a Multi-AZ DB instance for Amazon RDS AWS
Multi-AZ 容錯移轉通常需要 60～120 秒，切換後必須重新建立連線，建議 JVM 的 DNS 快取 TTL 設為 60 秒以下 - High availability for Amazon Aurora AWS
故障期間讀寫會失敗，通常在 60 秒內（常見為 30 秒內）恢復 - Semisynchronous Replication MySQL
非同步複寫在主 DB 故障時，已 commit 的 transaction 可能不在複本上；半同步複寫會等待一個複本確認收到來降低這種風險，代價是延遲增加 - Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
log 傳送（log shipping）是非同步的，主伺服器故障時，尚未送出的 transaction 會遺失；串流複寫的延遲通常不到 1 秒 - Amazon RDS event categories and event messages AWS
RDS-EVENT-0013：Multi-AZ 容錯移轉開始；RDS-EVENT-0049：Multi-AZ 容錯移轉完成 - Amazon CloudWatch metrics for Amazon RDS AWS
ReplicaLag：讀取複本落後來源的時間（秒） - The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_replication 的 replay_lag：主伺服器寫入 WAL 之後，到複本回報已套用為止所花的時間
相關原因
同一層：L12 資料庫
同一症狀（吃指令／回檔）在其他層的原因
查看含圖解與實驗的完整版卡片