• 学派吧-由新云网络独家赞助-https://www.sq9.cn。

MySQL 5.7并发复制和mysqldump相互阻塞引起的复制延迟-Linux运维日志

MySQL admin 3年前 (2018-09-30) 1223次浏览 已收录 0个评论 扫描二维码
文章目录[隐藏]

有需要服务器方面的需求和咨询,可以联系博主 QQ 7271895

本来MySQL BINLOG和SHOW PROCESSLIST命令属于八竿子打不着的两个事务,但在最近故障排查中,发现主库和从库已经存在很严重的复制延迟,但从库上显示slave_behind_master值为0,复制SQL线程与备份线程之间相互阻塞,但未报死锁

在从库上执行SHOW PROCESSLIST发现复制的SQL线程等待锁,而等待SQL的WHERE条件竟然是类似于WHERE C1=’ABC’ AND C2>’2018-03-01′ AND C2<‘2018-03-26’ 这种个范围查询,第一时间想到就是怎么是个基于STATEMENT的复制,不科学啊,我们生产环境统一使用基于ROW格式的复制,难道研发私自修改回话级别的复制格式?

使用MySQL Binlog导出日志一看:

发现真错怪研发同事啦,rbr_only=yes说明基于ROW格式进行复制,“SET TRANSACTION ISOLATION LEVEL READ COMMITTED”也是基于行格式复制的典型特征之一,last_committed和sequence_number用于MySQL 5.7版本中的并发复制,row_query后跟的是在主库上执行的原始SQL,也就是我们在从库SHOW PROCESSLIST中看到的SQL,但实际上从库执行的还是BINLOG部分,该BINLOG可以直接可以直接直接在从库上执行,也可以解析成一行行的数据DML操作,BINLOG部分如下:

==========================================================================================================

另外一个很有意思的问题,如果在从库上运行mysqldump进行备份,且从库上使用并行复制,会导致备份和复制相互阻塞:

在上面的阻塞中,多个SQL线程与备份线程相互之间阻塞,且MySQL无法有效检测出死锁环路而触发死锁的回滚机制,导致复制线程和备份作业相互hang住,需要DBA进行干预(取消备份或停止复制),在复制SQL线程被hang住期间,复制的IO线程仍可以正常工作接受到主库的Binlog信息,但slave_behind_master并不会随之增大,如果仅通过监控slave_behind_master值来判断主从复制延迟,则会导致延迟监控存在严重漏洞,因此在监控复制延迟时,除监控slave_behind_master值外,还需要监控主库binlog位置点和从库执行的binlog位置点。

如果有不懂的、欢迎加入我们学派吧。一起学习交流。右上角站长群


学派吧 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:MySQL 5.7并发复制和mysqldump相互阻塞引起的复制延迟-Linux运维日志
喜欢 (1)
[pay@sq9.cn]
分享 (0)
关于作者:
腾讯云-运维运维 QQ 690624
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

Optimized by WPJAM Basic