MySQL主從復制心跳機制配置與故障排查指南

前言

在 MySQL 主從復制架構中，經常會遇到一種令人困惑的現象：Slave 端顯示 Slave_IO_Running 和 Slave_SQL_Running 均為 Yes，Slave_SQL_Running_State 顯示 Slave has read all relay log; waiting for the slave I/O thread to update it，表面狀態一切正常，但實際上數據卻滯後於 Master。Master_Log_File 和 Read_Master_Log_Pos 也不是 Master 上最新的位置。這種情況下，雖然 Master 上的 binlog dump 線程可能掛了，但有時在 Master 上檢查卻一切正常。那麼，這種「假正常」的延遲究竟是怎麼造成的？

根因分析：TCP 連接的靜默斷裂

在 MySQL 的復制協議中，Slave 發送 COM_BINLOG_DUMP 命令後，數據推送完全由 Master 主導，雙方不再需要交互。若 Master 無數據更新，便無數據流產生，Slave 自然收不到數據包。然而，若因網絡故障或其他原因導致 Master 上的 TCP 連接丟失，由於 TCP 協議特性，Slave 無法收到斷開通知，因而無法判斷「收不到數據」是因為 Master 確無更新，還是連接已中斷。這就是導致「狀態正常但實際延遲」的核心原因。

解決方案：複製心跳功能

自 MySQL 5.5 起，引入了複製心跳功能，完美解決此問題。配置示例如下：

STOP SLAVE;
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10;
SET GLOBAL SLAVE_NET_TIMEOUT = 25;
START SLAVE;

上述配置使 Master 在無數據傳輸時，每 10 秒發送一個心跳包。slave_net_timeout 定義在多長時間未收到數據後判定網絡超時，超時後 Slave 的 IO 線程將自動重連 Master。兩者結合，有效避免網絡問題導致的複製延遲。需注意：master_heartbeat_period 單位為秒，支持毫秒級精度（如 10.5）。

關鍵參數默認值與配置建議

• slave_net_timeout 默認 3600 秒（1 小時）。未配置心跳時，若將其設得過短，會導致 Master 無更新時頻繁重連，增加負載。
• 建議組合：master_heartbeat_period 設為 10~30 秒，slave_net_timeout 設為心跳週期的 2~3 倍（如 30~60 秒），平衡敏感度與穩定性。

監控心跳狀態

奇怪的是，當前 master_heartbeat_period 值無法通過 SHOW SLAVE STATUS 查看，需使用 SHOW STATUS LIKE 'Slave_heartbeat_period'。相關狀態變量：

• Slave_last_heartbeat：最後一次收到心跳的時間
• Slave_received_heartbeats：累計收到心跳次數

示例輸出：

mysql> SHOW STATUS LIKE 'slave%';
+----------------------------+---------------------+
| Variable_name              | Value               |
+----------------------------+---------------------+
| Slave_heartbeat_period     | 5.000               |
| Slave_last_heartbeat       | 2014-05-08 11:48:57 |
| Slave_open_temp_tables     | 0                   |
| Slave_received_heartbeats  | 1645                |
| Slave_retried_transactions | 0                   |
| Slave_running              | ON                  |
+----------------------------+---------------------+

總結

配置複製心跳是保障 MySQL 主從復制高可用的關鍵最佳實踐。它通過主動探活機制，讓 Slave 能及時感知連接異常並自動恢復，避免了長時間的「靜默延遲」。生產環境中強烈建議啟用並合理調優相關參數。