한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

複寫延遲 Replication lag

原因 ID db-replica-lag · 主要負責 基礎設施團隊（DB 基礎設施） · 協同遊戲開發團隊（伺服器開發）

在含圖解與實驗的完整版中開啟卡片 →

寫入走主 DB、讀取走複本的架構下，複本跟得慢時，剛寫入的內容就會看不到。

為什麼 寫入集中湧向主 DB，複本落後數秒 → 於是從複本讀取剛存檔的內容時，資料還不存在 → 畫面上 剛買的道具看不到、交易所價格還是舊的、重複發放的 bug

症狀: 吃指令／回檔
因素: 延遲
誰會遇到: 只有特定功能
何時: 人潮湧入時, 晚間尖峰時段
負責單位: 主要負責 基礎設施團隊（DB 基礎設施） · 協同遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 剛寫入的資料從主 DB 讀取；確認是否已發放與實際發放，在主 DB 上以同一個 transaction 完成（用唯一鍵或條件式 UPDATE 防止重複）。
基礎設施團隊要做的事: 設定複寫延遲警示、讓複本規格不低於主 DB 並啟用平行複寫、大量刪除分成小批執行、管理在複本上長時間執行的彙總查詢。
圖表上: 隨人數／負載上升 · 複寫延遲（秒）
查看位置: 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 卻仍看不到時，是遊戲伺服器的快取或同步的問題
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）
深入了解: 即使寫入不多也可能落後。在主 DB 上花了 10 分鐘的一次大量刪除，在複本上重新執行的期間，也會讓複本落後同樣的時間；在複本上長時間執行的彙總查詢，也會拖慢複本追上的速度。

出處

SHOW REPLICA STATUS Statement MySQL
Seconds_Behind_Source：複本目前正在套用的事件，與該事件在主 DB 上寫入的時間之差（複寫延遲）
Replica Server Options and Variables MySQL
用 replica_parallel_workers 讓多個執行緒平行套用 transaction（預設 4；設為 0 時由單一執行緒依序套用）
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
串流複寫預設為非同步，commit 與複本套用之間有延遲（複本跟得上時通常不到 1 秒）
MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement MySQL
從 8.0.22 起以 SHOW REPLICA STATUS 取代 SHOW SLAVE 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：讀取複本落後來源的時間（秒）

複寫延遲 Replication lag

出處

相關原因

同一層：L12 資料庫

同一症狀（吃指令／回檔）在其他層的原因