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;

 

posted on 2020-03-12 16:16  igoodful  阅读(52)  评论(3编辑  收藏

导航