wait_timeout 、interactive_timeout、slave_net_timeout、master_heartbeat_period

1）slave_net_timeout，默认值是60s，是从库端主动发起重新连接请求，避免主库重启后而从库却傻傻地原地等待这种情况。表示slave在slave_net_timeout时间之内没有收到master的任何数据(包括binlog和heartbeat)，slave认为连接断开，会进行重连。
   超时后，先断开io线程，再立刻通过开启io线程发起重连请求。后续重连的时间间隔由chnage master to命令的master_connect_retry参数指定。slave_net_timeout如果设置太大，那么主库重启后，从库将会长时间无法同步主库数据，这时需要重启io线程。
   因此，该参数很重要，不宜设置太大，同样也不要设置太小，太小的话，就会出现从库频繁向主库发起连接请求。一般将该值设置为：30s到300s之间。即默认值即可。

2）master_connect_retry默认值为60s。表示重连的时间间隔。重连次数上限由master_retry_count定义，默认值3600s，即1小时。
   当重新建立主从连接时，如果连接建立失败，间隔多久后重试。

3）master_retry_count默认值86400次。表示重连的最大次数。
# 作为一个从库，一旦和某个主库建立了主从关系，并且开始正常的复制后，如果与主库失联时间超过slave_net_timeout时间，则触发从库向主库发起重连请求：
  如果重试的过程中，连上了主库，那么它认为当前主库是好的，又会开始 slave-net-timeout 秒的等待。
  如果从库向主库发起的重连请求依旧没有收到主库的binlog数据和心跳数据，则从库再等待master_connect_retry时间，如果master_connect_retry时间到了后，还是没有收到主库的binlog数据和心跳数据，则继续重复上述等待master_connect_retry时间、发起请求的过程
  这个过程最长能持续多久呢？那就是从库每次等待master_connect_retry时间，次数是master_retry_count，当达到了master_connect_retry*master_retry_count时间后，还是没有收到主库的binlog数据和心跳数据，那就是彻底断开主从关系。
  这个时间是多久呢？假设master_connect_retry=60s，master_retry_count=86400，那么这就是60天的时间，足够大了。

4）master_heartbeat_period，默认值为slave_net_timeout参数值得一半。表示主库心跳时间。主库在没有数据更新的时候，每过master_heartbeat_period时间就发送一个心跳包给所有从库，这样从库就能知道主库还健在。
  在 mysql 的复制协议里，由 slave 发送一个 com_binlog_dump 命令后，就完全由 master 来推送数据，master、slave 之间不再需要交互。如果 master 没有更新，也就不会有数据流，slave 就不会收到任何数据包。
  但是如果由于某种原因造成 master 无法把数据发送到 slave ，比如发生过网络故障或其他原因导致 master 上的 tcp 连接丢失，由于 tcp 协议的特性，slave 没有机会得到通知，所以也没法知道收不到数据是因为 master 本来就没有更新呢还是由于出了故障。
  mysql5.5提供的新的配置master_heartbeat_period。即复制心跳，能够在复制停止工作和出现网络中断的时候帮助我们迅速发现问题。

#########################################################

5）设置参数

stop slave;

change master to master_heartbeat_period = 10;

start slave;