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)