MySQL 主從複制心跳機制：解決 Slave 假掛起、延遲誤判問題

MySQL 5.5+ 引入複制心跳功能，解決傳統複制中「網路中斷無感知、Slave 狀態顯示正常實際延遲」的核心痛點。本文詳細解析原理、配置、監控指標。

問題背景：為什麼需要心跳？

傳統複制協議：Slave 發送 COM_BINLOG_DUMP 後，完全由 Master 推送數據。若 Master 無寫入，無數據流；若網路中斷，TCP 連接未必立即斷開，Slave 無法區分「Master 閒置」與「連接斷開」，導致：

• Slave_IO_Running=Yes、Slave_SQL_Running=Yes 但實際未同步
• Seconds_Behind_Master 不準確
• 預設 slave_net_timeout=3600 (1小時) 才會嘗試重連

心跳機制原理

1. Master 無數據推送時，每 master_heartbeat_period 秒發送一個心跳包
2. Slave 收到心跳更新 Slave_last_heartbeat 時間戳
3. 若超過 slave_net_timeout 秒未收到任何數據(含心跳)，Slave IO 線程判定超時，主動重連

配置步驟

STOP SLAVE;

-- 設定心跳間隔 10 秒 (單位：秒，支援毫秒精度如 10.5)
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10;

-- 設定網路超時 25 秒 (需大於心跳間隔，建議 2-3 倍)
SET GLOBAL SLAVE_NET_TIMEOUT = 25;

START SLAVE;

關鍵公式： slave_net_timeout > master_heartbeat_period * 2，避免誤判。

監控指標 (SHOW STATUS LIKE 'Slave%')

mysql> SHOW STATUS LIKE 'Slave%';
+----------------------------+---------------------+
| Variable_name              | Value               |
+----------------------------+---------------------+
| Slave_heartbeat_period     | 5.000               |  -- 當前心跳間隔
| Slave_last_heartbeat       | 2014-05-08 11:48:57 |  -- 最後收到心跳時間
| Slave_received_heartbeats  | 1645                |  -- 累計收到心跳次數
| Slave_open_temp_tables     | 0                   |
| Slave_retried_transactions | 0                   |
| Slave_running              | ON                  |
+----------------------------+---------------------+

注意： master_heartbeat_period 無法從 SHOW SLAVE STATUS 看到，必須用 SHOW STATUS 查看。

版本差異與最佳實踐

常見誤區

1. 心跳間隔設太短 (如 0.1 秒) → 增加網路開銷、CPU 佔用
2. 未調整 slave_net_timeout → 預設 1 小時，心跳失效
3. 混淆 Seconds_Behind_Master → 該值基於 SQL 線程進度，非實時網路狀態
4. 忽略防火牆/NAT 超時 → 需確保網路設備空閒超時 > slave_net_timeout

故障排查清單

-- 1. 確認心跳生效
SHOW STATUS LIKE 'Slave_heartbeat_period';

-- 2. 確認網路超時設定
SHOW VARIABLES LIKE 'slave_net_timeout';

-- 3. 模擬網路中斷測試
# Master 防火牆封鎖 Slave IP
# 觀察 Slave 多久後 IO 線程重連 (應接近 slave_net_timeout)

-- 4. 檢查錯誤日誌
grep -i "heartbeat\|timeout\|reconnect" /var/log/mysql/error.log