首页> 知识分享 >其它分享 其它分享

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

作者:小萝卜 2019-05-30 浏览 2113

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

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

分类: Mysql/postgreSQL2015-03-17 10:49:50

【现象】

主备两台服务器,备用机断网一段时间,主机有数据更新,后来备机重新联网,发现需要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 这两个时间参数,以及它们之间的关系。

 

 

很赞哦! (0)

文章评论

    高端网站建设