请不要用SECONDS_BEHIND_MASTER来衡量MYSQL主备的延迟时间

链接:http://www.woqutech.com/?p=1116

MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是今天碰到了一个场景,发现 Seconds_Behind_Master 为 0 , 备库的 show slave status 显示 IO/SQL 线程都是正常的 , MySQL 的主库上的变更却长时间无法同步到备库上。如果没有人为干预,直到一个小时以后,MySQL 才会自动重连主库,继续复制主库的变更。

影响范围: MySQL , Percona , MariaDB 的所有版本。

虽然这种场景非常特殊,遇到的概率并不高,但是个人觉得有必要提醒一下使用 MySQL 的 DBA 们。通过对这个场景的分析,也有助于我们更加深入的理解 MySQL replication 重试机制。

一、重现步骤

搭建主备的复制,临时断开主库的网络,并 kill 掉主库 MySQL 的 binlog dump 线程。

此时观察备库的复制情况, show slave status 中:

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Seconds_Behind_Master: 0

但是此时你把网络恢复以后,在主库做任何变更,备库都无法获得数据更新了。而且备库上的show slave status 显示: IO 线程 SQL 线程一切正常,复制延迟一直是 0 。

一切正常,普通的监控软件都不会发现备库有数据延迟。

二、原理分析

MySQL 的 Replication 是区别于其他数据库很关键的地方。也是可扩展性和高可用的基础。它本身已经非常智能化,只需要我们调用 Change Master 指定 Binlog 文件名和偏移位置就可以搭建从主库到备库的复制关系。

MySQL 复制 线程 会自动将目前复制位置记录下来,在主备复制中断的时候自动连上主库,并从上次中断的位置重新开始复制。这些操作都是全自动化的,不需要人为的干预。这给了 MySQL DBA 带来了很多便利,同时却也隐藏了很多细节。

要真正的理解前面问题的真相以及怎么解决这个问题,我们还是需要真正的理解 MySQL  复制的原理。

2.1“推”还是“拉”

首先, MySQL 的复制是“推”的,而不是“拉”的。“拉”是指 MySQL 的备库不断的循环询问主库是否有数据更新,这种方式资源消耗多,并且效率低。“推”是指 MySQL 的主库在自己有数据更新的时候推送这个变更给备库,这种方式只有在数据有变更的时候才会发生交互,资源消耗少。如果你是程序员出身,你一定会选择“推”的方式。

那么 MySQL 具体是怎么“推”的列,实际上备库在向主库申请数据变更记录的时候,需要指定从主库Binlog 的哪个文件 ( MASTER_LOG_FILE ) 的具体多少个字节偏移位置 ( MASTER_LOG_POS ) 。对应的,主库会启动一个 Binlog dump 的线程,将变更的记录从这个位置开始一条一条的发给备库。备库一直监听主库过来的变更,接收到一条,才会在本地应用这个数据变更。

2.2 原因解析

从上面的分析,我们可以大致猜到为什么 show slave status 显示一切正常,但是实际上主库的变更都无法同步到备库上来:

出现问题的时候, Binlog dump 程序被我们 kill 掉了。作为监听的一方,备库一直没有收到任何变更,它会认为主库上长时间没有任何变更,导致没有变更数据推送过来。备库是无法判断主库上对应的Binlog dump 线程 到底是意外终止了,还是长时间没有任何数据变更的。所以,对这两种情况来说,备库都显示为正常。

当然, MySQL 会尽量避免这种情况。比如:

l  在 Binlog dump 被 kill 掉时通知备库 线程 被 kill 掉了。所以我们重现时需要保证这个通知发送不到备库,也就是说该问题重现的关键在于 Binlog dump 被 kill 的消息由于网络堵塞或者其他原因无法发送到备库。

l  备库如果长时间没有收到从主库过来的变更,它会每隔一段时间重连主库。

2.3 问题避免

基于上面的分析,我们知道 MySQL 在这种情况下确实无法避免,那么我们可以有哪些办法可以避开列:

1.  被动处理:修改延迟的监控方法,发现问题及时处理。

2.  主动预防:正确设置 --master-retry-count ,  --master-connect-retry ,  --slave-net-timeout 复制重试参数。

l  被动处理

MySQL 的延迟监控大部分直接采集 show slave status 中的  Seconds_Behind_Master 。这种情况下,Seconds_Behind_Master 就无法用来真实的衡量主备之间的复制延迟了。我们建议通过在主库轮询插入时间信息,并通过复制到备库的时间差来获得主备延迟的方案。 Percona 提供了一种类似的方案 pt-heartbeat 。

发现这个问题以后,我们只需要 stop slave; start slave; 重启复制就能解决这个问题。

l  主动预防

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 设置的过小也有问题,这样会导致如果主库的变更确实比较少的时候,备库频繁的重新连接主库,造成资源浪费。

沃趣科技的 Q Monitor 监控中对主备复制的延迟监控,并不是通过 Seconds_Behind_Master 来监控主备的。它采用了类似于 pt-heartbeat 的方式对主备进行复制延迟监控。

时间: 2024-11-08 21:40:21

请不要用SECONDS_BEHIND_MASTER来衡量MYSQL主备的延迟时间的相关文章

请不要用SECONDS_BEHIND_MASTER来衡量MYSQL主备的延迟时间【转】

本文来自:http://www.woqutech.com/?p=1116 MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是 今天碰到了一个场景,发现 Seconds_Behind_Master 为 0 , 备库的 show slave status 显示IO/SQL 线程都是正常的 , MySQL 的主库上的变更却长时间无法同步到备库上.如果没有人为干预,直到一个小时以后, MySQL 才会自动重连主

LVS+MYCAT+读写分离+MYSQL主备同步部署手册

LVS+MYCAT+读写分离+MYSQL主备同步部署手册 1          配置MYSQL主备同步…. 2 1.1       测试环境… 2 1.2       配置主数据库… 2 1.2.1         编辑my.cnf文件… 2 1.2.2         重启数据库… 2 1.3       锁定主数据库DDL操作… 2 1.4       主备已有数据同步… 2 1.5       停止从服务… 3 1.6       配置备用数据库… 3 1.6.1         编辑my

【转载】LVS+MYCAT+读写分离+MYSQL主备同步部署手册(邢锋)

By leo | 2015/05/13 0 Comment LVS+MYCAT+读写分离+MYSQL主备同步部署手册 1          配置MYSQL主备同步…. 2 1.1       测试环境… 2 1.2       配置主数据库… 2 1.2.1         编辑my.cnf文件… 2 1.2.2         重启数据库… 2 1.3       锁定主数据库DDL操作… 2 1.4       主备已有数据同步… 2 1.5       停止从服务… 3 1.6      

LVS+Keepalived+Mysql+主备数据库架构

这是一个坑...磨了不少时间.见证自己功力有待提升... 架构图 数据库 1.安装数据库 这块不难, 直接引用:mysql安装 2.数据库主备 这块不难, 直接引用: mysql主备 虚拟VIP 重点来了!! 上脚本, 把这个脚本命名后仍进/etc/init.d, 然后授予权限755或者+x SNS_VIP=192.168.158.110 /etc/rc.d/init.d/functions case "$1" in start) ifconfig eth0:0 $SNS_VIP ne

mysql主备复制搭建(使用mysqld_muti)

这里我使用单台服务器上的两个mysql实例进行搭建,主要用到了mysql自带的mysqld_multi 一.复制原理 开始搭建前有个mysql复制原理的基础知识需要补充: mysql进行主备复制使用到了三个线程: 1.主库上的转存储线程: 会将mysql server提交的事务写入到二进制文件中,这个二进制文件就叫做binlog. 2.备库上的连接线程: 备库启动后,负责和主库通信,读取binlog,同时,将binlog存储进自己的一个叫中继日志的relaylog中. 3.备库上的relaylo

MySQL主备库切换演练与总结

演练包括被动切换和主动切换两部分.被动切换是主库宕机,主动切换是人工手动触发. 演练步骤大致如下: 1 先停掉主库,模拟主库宕机 2 mha将vip切到备库,备库变成主库,应用可以正常读写数据库 3 重新启动宕机的原主库 4 在原主库上建立同步关系(根据宕机时,日志记录的binlog的文件名和偏移量,恢复从这里开始) 5 mha手动切换主库,还原到最初状态,应用可以正常读写数据库 6 演练结束 演练过程问题总结: 1 mha每次自动切换之后都会结束自身进程,并在日志目录如/app/mha/xxx

mysql主备配置方法

主备复制配置 1,主备创建账号 GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO [email protected]’172.16.0.%’ IDENTIFIED BY ‘rep’; 2,配置主库 My.cnf log_bin=mysql-bin server_id=10 innodb_flush_log_at_trx_commit=1 sync_binlog=1 3,配置从库 log_bin=mysql-bin server_id=2 r

MYSQL主备复制结构搭建

1 选择两个服务器,分别作为主备数据库 2 登陆到服务器, yum install mysql ; yum install mysql-server; 3 启动服务器 service  mysqld start 4 分别root登陆mysql 执行如下命令,增加复制用户并授权(主备都在192.168.119.*网段,为了方便主备切换,两边都建立) GRANT  REPLICATION SLAVE,REPLICATION CLIENT on *.* to [email protected]'192

MySQL主备停机步骤与注意事项

双十一马上到了,一堆的事情,今天登录mysql数据库服务器的时候突然发现服务器时间戳不对,比北京时间快了几分钟,我的天...随后检查了其他的几台数据库服务器发现同样都存在不同的偏差,最小的比北京时间快几秒,最大的长达8分钟,感觉整个人都不舒服了...服务器时间戳没有同步会导致什么问题呢,举个最简单的例子你的程序代码里面用now()来获取时间,比如一个订单,你最终会发现订单的处理时间竟然比订单的创建时间来到早,马爸爸和东哥要是知道了还不得发飙啊!!! 随后要做的事情就是改服务器时间了,改服务器时间