在 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 開始增加了一個復制心跳的功能。

如

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 表示總共收到的心跳次數。

如：