Mysql主备半小时后才会同步的问题

【现象】
主备两台服务器，备用机断网一段时间，主机有数据更新，后来备机重新联网，发现需要30分钟到1小时才能将数据同步过去。

【预备知识】
SHOW PROCESSLIST\G 查看主数据库的复制线程（binlog dump 线程）的状态，以及备数据库I/O线程和SQL线程的状态。
重点关注 Time 字段（表示等了多少秒）和 State字段（表示处于什么状态）。
SHOW SLAVE STATUS\G 查看 Slave_IO_Running 和 Slave_SQL_Runnig 字段的状态，如果为 No，表示备数据库的两个线程没运行。
START SLAVE 命令用于开始复制，备数据库的两个线程会运行起来，Slave_IO_Running 和 Slave_SQL_Runnig 字段的状态为 Yes。

【分析过程】
DB01 为主；DB02为备。
DB02 断网，DB01 上使用 show processlist\G 查看 DB01 的线程，发现 DB01 的 binlog dump 线程状态会变为“writing in net”，一分钟后线程消失（DB01 的 binlog dump 线程用于将 DB01 上的 binlog 日志发送给 DB02）。DB02重新联网，等了1个小时后，DB01 的 binlog dump 线程重新出现。
查看资料，是 slave 端（备数据库，这里为 DB02）的 I/O 线程处于 “waiting for master to send event”状态，如果这个等待状态超过 slave_net_timeout 时间，就会触发重连 master 的动作。
使用 show VARIABLES; 命令查看系统变量，找到 slave_net_timeout 的值，为 3600，即一小时后 DB02 重连 DB01，之后 DB01 的 binlog dump 线程重新启动，开始数据同步过程。

【总结】
备机断网（拔网线），主机有数据写入，主机要写 binlog 并通过 binlog dump 线程把这个文件发给备机，由于连不上备机，所以这个线程会处于 writing in net 状态，一分钟后实在连不上，判定 slave 不存在，于是 binlog dump 线程退出。这里一共花了 X+1 分钟。
备机重新上线（插回网线），IO 线程从一开始（最近一次处理完主机发送过来的 binlog 文件那一刻，即在断网之前）就处于“waiting for master to send event”状态，就是一直等着主机发 binlog 文件过来，等到3600秒后实在等不下去，就重连主机。slave 重连主机，才会导致主机 binlog dump 线程启动。

|-备机断网-----------------------------------------------Y分钟后备机上线--------------------------------------------------|
|-备机IO线程重新计时--------------------------------------------------------------------------------------3600秒后重连主机|
|---X分钟后主机发送 binlog 文件---1分钟后 binlog dump 线程退出------------------------------binlog dump 线程启动，同步完成|

上面直线表示时间前进方向，三行分别表示三个角度（备机断网后上线、备机IO线程发生的事情、主机 binlog dump 线程发生的事情）在同一时间域上发生的事情。结论就是备机上线后数据重新同步所需要的时间是一个小时以内，具体多少，与X分钟和Y分钟有关：如果X>Y，即备机上线后主机再发送 binlog 文件，是马上就同步的；如果X 这就是有时候会马上同步，有时候会30分钟到1小时都会同步的原因。我们在测试的时候都没有注意 X 与 Y 这两个时间参数，以及它们之间的关系。