MySQL主从复制配置心跳功能介绍

这篇文章主要为大家详细介绍了MySQL主从复制配置心跳功能介绍，具有一定的参考价值，可以用来参考一下。

对此感兴趣的朋友，看看idc笔记做的技术笔记！

在 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;

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)

注：关于MySQL主从复制配置心跳功能介绍的内容就先介绍到这里，更多相关文章的可以留意