MySQL主从延迟Seconds_Behind_Master计算方式

MySQL主从延迟Seconds_Behind_Master计算方式,第1张

这样计算的问题:

1、 首先这样的计算方法本身是不对的,如果本地时间有问题会导致event时间戳不准,从而出现误差,所以计算公式中会记录一下主从库的当前时间差

公式如下:

注意:这个时间差只会在主从线程启动时计算一次,所以start slave后如果主从本地时间出现异常,Seconds_Behind_Master也是不准的,需要重启复制线程重新计算主从本地时间差异(如果最终计算结果是负数,会归零)

2、 如果IO线程出现延迟,此时这个值是有误差的,Seconds_Behind_Master可能显示为0,但实际和主库是有延迟的,容易出现误差

提示:所以只拿这个值来做复制延迟的监控是不准的,一般都会配合心跳表的时间戳来判断当前延迟

每次进行show slave status时都会进行一次计算

源码如下:

这里可以看到判断SQL线程是否应用所有的event

注意:此时如果IO线程有延迟则即使Seconds_Behind_Master=0但是还是有延迟

关键词解释

单线程复制和并行复制对于last_master_timestamp这个的计算也是不同的

ev->when.tv_sec表示事件的开始时间。exec_time指事件在主库的执行时间,GTID_EVENT和XID_EVENT才会统计exec_time

总结:事务执行中的event时间都是事务开始时begin的时间戳,GTID_EVENT和XID_EVENT则是事务提交的时间,所以如果存在事务长时间未提交就会出现延迟突然增大然后正常的情况

先了解一下并行复制的流程

这导致并行复制和单线程复制之间复制延迟会有差异,差异是slave_checkpoint_period + 事务在备库执行的时间,这就是有时单线程无延迟,换到并行复制反而有轻微延迟的原因

另外DDL的时间戳计算其实是事务执行时间+事务开始时间

本文主要讲述了seconds_behind_master在不同模式下的计算方式,很多情况会导致这个参数不准确,所以也建议大家还是结合心跳表配合监控延迟比较准确,如有理解偏差欢迎随时指正

本文参考:

大致流程:主库将变更写binlog日志,然后从库连接到主库之后,从库有一个IO线程,将主库的binlog日志拷贝到自己本地,写入一个中继日志 relay日志中。接着从库中有一个SQL线程会从中继日志读取binlog,然后执行binlog日志中的内容,也就是在自己本地再次执行一遍SQL,这样就可以保证自己跟主库的数据是一样的。

如果主库突然宕机,然后恰好数据还没同步到从库,那么有些数据可能在从库上是没有的,这时候从库成为了主库,那么有些数据可能就丢失了。

开启半同步复制 semi-sync ,用来解决主库数据丢失问题;

这个所谓半同步复制, semi-sync复制 ,指的就是主库写入binlog日志之后,就会将强制此时立即将数据同步到从库,从库将日志 写入自己本地的relay log之后 ,接着会 返回一个ack 给主库, 主库接收到至少一个从库的ack之后才会认为写 *** 作完成了。 如果 过程出现失败 ,那么 我们的客户端就可以进行重试了 ;

主从延迟对于读写分离的涉及影响比较大

这里有一个非常重要的一点,就是 从库同步主库数据的过程是串行化的 ,也就是说 主库上并行的 *** 作,在从库上会串行执行 。所以这就是一个非常重要的点了,由于从库从主库拷贝日志以及串行执行SQL的特点,在 高并发场景下,主库大量的写,那么从库的数据一个个的读,那么就会导致从库同步一定会比主库慢一些,是有延时的 。所以经常出现,刚写入主库的数据可能是读不到的,要过几十毫秒,甚至几百毫秒才能读取到。(主库并发写的量级越高,从库积压的同步数据越多,延迟越高)

我们可以用 show status 看看 Seconds_Behind_Master 参数,你可以看到从库复制主库的数据落后了几ms,但是这个也不是完全准确,可以看 Seconds_Behind_Master的

对于解决主从延迟,解决方案可以从以下方面考虑

在主服务器上建立一个为从服务器进行复制使用的用户。该账户必须授予 REPLICATION SLAVE 权限,由于仅仅是进行复制使用所以不需要再授予任何其它权限。

mysql>GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%'192.168.0.2' IDENTIFIED BY 'slavepasswd'

mysql>FLUSH PRIVILEGES

3、编辑主服务器的配置文件:/etc/my.cnf的[ mysqld ] 部分:

server-id = 本机数据库 ID 标示,该部分还应有一个server-id=Master_id选项,其中master_id必须为1到232之间的一个正整数值

log-bin = 二进制日志的位置和名称

binlog-do-db = 需要备份的数据库名,如果备份多个数据库,重复设置这个选项即可

binlog-ignore-db = 不需要备份的数据库苦命,如果备份多个数据库,重复设置这个选项即可


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/6123080.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-15
下一篇 2023-03-15

发表评论

登录后才能评论

评论列表(0条)

保存