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_Log_File 和 Read_Master_Log_Pos 也不是實際主上最新的位置。一種可能是 Master 上的 binlog dump 執行緒掛了。但有時候，在 Master 上檢查也是完全正常的。那 Slave 的延誤又是怎麼造成的呢？

在 MySQL 的複製協議裡，由 Slave 傳送一個 COM_BINLOG_DUMP 命令後，就完全由 Master 來推送資料，Master、Slave 之間不再需要互動。如果 Master 沒有更新，也就不會有資料流，Slave 就不會收到任何資料包。但是如果由於某種原因造成 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 就能知道 Master 是不是還正常。slave_net_timeout 是設定在多久沒收到資料後認為網路超時，之後 Slave 的 IO 執行緒會重新連線 Master 。結合這兩個設定就可以避免由於網路問題導致的複製延誤。master_heartbeat_period 單位是秒，可以是個帶上小數，如 10.5。最高精度為 1 毫秒。

slave_net_timeout 的預設是 3600，也就是一小時。也就是說，在之前的情況下，Slave 要延誤 1 小時後才會嘗試重連。而在沒有設定 master_heartbeat_period 時，將 slave_net_timeout 設得很短會造成 Master 沒有資料更新時頻繁重連。

很奇怪的是，當前的 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                  |
+----------------------------+---------------------+
6 rows in set (0.00 sec)