MySQL Slave 延遲監控深度解析：Seconds_Behind_Master 不夠準，教你三步精準判斷

MySQL Slave 延遲監控深度解析：Seconds_Behind_Master 不夠準，教你三步精準判斷

常見誤區

僅看 Seconds_Behind_Master（SBM）判斷延遲，**大部分情況可接受但不夠精準**，需綜合多指標。

關鍵狀態欄位解讀

SHOW SLAVE STATUS\G
Master_Log_File: mysql-bin.000327
Read_Master_Log_Pos: 668711237
Relay_Log_File: mysql-relay-bin.002999
Relay_Log_Pos: 214736858
Relay_Master_Log_File: mysql-bin.000327
Exec_Master_Log_Pos: 654409041
Relay_Log_Space: 229039311
Seconds_Behind_Master: 3296

兩個 Replication 執行緒狀態

SHOW FULL PROCESSLIST\G
-- IO 執行緒
Id: 6, State: Waiting for master to send event, Time: 22005006
-- SQL 執行緒
Id: 7, State: Updating, Time: 3293, Info: UPDATE ...

Time 欄位含義

• SQL 執行緒：當前執行 binlog 的 timestamp 與 IO 執行緒最新 timestamp 差值 = SBM；無活躍 SQL 時 = idle time
• IO 執行緒：啟動以來總秒數；系統時間調整可能導致異常值（負數或極大）

三步精準判斷延遲法

步驟 1：比對 Relay_Master_Log_File vs Master_Log_File

• 相同 → SQL 執行緒處理同一 binlog，看 Position 差異
• 不同 → SQL 執行緒落後至少一個 binlog，延遲較大

步驟 2：同一 binlog 時，比對 Exec_Master_Log_Pos vs Read_Master_Log_Pos

差值 = SQL 執行緒比 IO 執行緒慢多少個 binlog 事件。

步驟 3：不同 binlog 時，需從 Master 取得 binlog 列表計算總差距

-- Master
SHOW BINARY LOGS;
+------------------+--------------+
| Log_name         | File_size    |
+------------------+--------------+
| mysql-bin.000009 | 1073742063   |
| mysql-bin.000010 | 107374193    |
+------------------+--------------+

-- Slave 狀態
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
Exec_Master_Log_Pos: 654409041

精確延遲計算

-- 當前 binlog 剩餘事件
1073742063 - 654409041 = 419,333,022 events

-- 加上下一個 binlog 已產生事件
107374193 + 419,333,022 = 526,707,215 events 總延遲

生產環境監控最佳實踐

在**第三方監控節點**同時對 Master/Slave 發起：

• SHOW BINARY LOGS (Master)
• SHOW SLAVE STATUS\G (Slave)
• 綜合比對 binlog 文件差異 + Position 差異

💡 核心心法：SBM 只是「SQL 執行緒覺得自己落後多久」，**真實延遲 = Master 已生成事件 - Slave 已執行事件**，需雙端採樣計算。