由于本人做几套DNS系统，其中部分系统使用 BIND + MYSQL 结构，

这个结构就需要做 MYSQL 主从复制实现DNS数据同步~

最近发现这样的故障：

一台MYSQL数据同步缓慢（1个小时之后才会被更新），本来是瞬间同步的。

分析前人和别人的文章内容：

 

“MySQL 可以指定三个参数，用于复制线程重连主库： --master-retry-count ，  --master-connect-retry ，  --slave-net-timeout 。

其中 master-connect-retry 和 master-retry-count 需要在 Change Master 搭建主备复制时指定，而 slave-net-timeout 是一个全局变量，可以在 MySQL 运行时在线设置。

具体的重试策略为：备库过了 slave-net-timeout 秒还没有收到主库来的数据，它就会开始第一次重试。然后每过 master-connect-retry 秒，备库会再次尝试重连主库。直到重试了 master-retry-count 次，它才会放弃重试。如果重试的过程中，连上了主库，那么它认为当前主库是好的，又会开始 slave-net-timeout 秒的等待。

slave-net-timeout 的默认值是 3600 秒， master-connect-retry 默认为 60 秒， master-retry-count 默认为 86400 次。也就是说，如果主库一个小时都没有任何数据变更发送过来，备库才会尝试重连主库。这就是为什么在我们模拟的场景下，一个小时后，备库才会重连主库，继续同步数据变更的原因。

这样的话，如果你的主库上变更比较频繁，可以考虑将 slave-net-timeout 设置的小一点，避免主库 Binlog dump 线程 终止了，无法将最新的更新推送过来。 ”

 

分析之后结论——设置slave-net-timeout 的数值小一些，

方案一：

编辑my.cnf 文件加入参数
slave-net-timeout = 600，重启服务生效 （注意，此处为中划线 slave net timeout 之间）

方案二：本人建议使用此方案

set global slave_net_timeout=600;不需要重启即刻生效。（注意此处为下划线）