MySQL|主从延迟问题排查(一)-阿里云开发者社区

开发者社区> 袋鼠云> 正文

MySQL|主从延迟问题排查(一)

简介: 大查询长时间执行无法释放DML读锁,后续同步主库的DDL操作获取DML写锁资源被阻塞等待,导致后续同步主库的操作堆积,主从延迟增长严重。从同步延迟的监控来看,延迟从17:11开始,17:51:59进行kill大查询操作,直到17:53建议业务方将大查询kill掉后才结束。
+关注继续查看

一、案例分享

1.1 问题描述

大查询长时间执行无法释放DML读锁,后续同步主库的DDL操作获取DML写锁资源被阻塞等待,导致后续同步主库的操作堆积,主从延迟增长严重。从同步延迟的监控来看,延迟从17:11开始,17:51:59进行kill大查询操作,直到17:53建议业务方将大查询kill掉后才结束。

1.2 处理流程

1、当接收到只读实例的同步延迟告警后,登录到RDS的管理控制台查看实例当前会话执行情况,判断只读实例当前负载压力。从当前会话截图可以看到,会话并无明显堆积,但是有两个执行时间很久的大查询操作。

2、17:11延迟开始,17:51 kill大查询,17:53主从延迟恢复。我们仍需要排查这个期间主实例和只读实例的运行情况,分析造成主从延迟的具体原因

3、对主实例的排查

1)查看延迟期间主库是否有一些批处理/大事务操作,主库业务业务请求上涨或者有批量的更新操作。对此,我们主要观察主实例的QPS/TPS监控、MySQL_COMDML和日志读写的监控指标。

从以上截图中可以看到,主库TPS在主从延迟期间并没有明显的上涨,说明期间主库业务压力正常;主库MySQL_COMDML和日志读写在主从延迟期间也没有明显的上涨,说明期间主库也没有执行一些批量更新的大事务操作。

2)查看延迟期间主库是否有执行消耗较大的DDL操作。在RDS中若开启了审计日志,我们可以通过时间以及操作类型进行过滤排查

通过对审计日志的搜索,我们搜查到一条对视图定义进行alter的操作,该alter操作仅仅执行了2.32ms,其资源消耗本身并不大。

4、对只读实例的排查

1)查看延迟期间只读实例是否有较大负载压力,从只读实例延迟期间的会话执行情况以及资源消耗可以知道,延迟期间只读实例并无较大负载压力

2)从只读实例的QPS/TPS监控中可以看到,17:51kill掉大查询后只读实例的TPS异常上涨,17:53TPS恢复正常,延迟恢复。说明17:51~17:53期间只读实例在大量应用主库传输过来的binlog日志,恢复主从复制延迟。

5、捕捉延迟期间会话中的异常现象,大查询长时间执行未结束,执行explain操作显示为MDL锁等待,结合我们在主库审计日志中搜索到的alter操作,我们可以推断造成主从延迟的原因可能是只读实例大查询阻塞了从主库传输过来的Alter操作,导致后续延迟一直上涨,并在我们kill掉大查询后恢复。

6、为了印证我们的猜想,我们通过审计日志把相关操作的时间线进行梳理

  • 只读实例view_order_logistics_new相关的大查询执行了3602s还未执行完,一直持有表的DML读锁,不影响表的正常读写操作
  • 17:10 主库执行了ALTER ALGORITHM=UNDEFINED DEFINER=super_sha_prd_db@% SQL SECURITY DEFINER VIEW view_order_logistics_new 的操作
  • 只读实例view_order_logistics_new的大查询仍在执行中,此时主库执行alter操作传输到只读实例,alter操作需要的DML写锁与大查询持有的DML读锁冲突
  • alter操作无法获取到DML写锁从而开始等待锁资源,从主控传输过来的binlog也被阻塞,主从延迟开始上涨
  • 17:51:59 只读实例kill掉了view_order_logistics_new的大查询,只读实例TPS上涨,只读实例开始应用alter操作之后的所有binlog日志
  • 17:53:08 只读实例TPS恢复,应用延迟期间的binlog完毕,主从复制恢复正常

更多技术信息请查看云掣官网https://www.dtstack.com/dtsmart/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MySQL|主从延迟问题排查(二)
主库执行insert  select 批量写入操作,主从复制通过row模式下转换为批量的insert大事务操作,导致只读实例CPU资源以及延迟上涨
1241 0
【 OSS 排查方案-9 上传 OSS 延迟超时】
基础排查 一、 上传 OSS 出现慢的场景,OSS 会返回一个 requestID 属性,请保留这个 requestID 这是 OSS 所有信息的查询入口,升级阿里云时可以快速定位问题,如果上传超时的话时没有这个属性的。
5705 0
百万TPS高吞吐、秒级低延迟,阿里​搜索离线平台如何实现?
阿里主搜(淘宝天猫搜索)是搜索离线平台非常重要的一个业务,具有数据量大、一对多的表很多、源表的总数多和热点数据等特性。对于将主搜这种逻辑复杂的大数据量应用迁移到搜索离线平台总是不缺少性能的挑战,搜索离线平台经过哪些优化最终实现全量高吞吐、增量低延迟的呢?
1005 0
百万TPS高吞吐、秒级低延迟,阿里​搜索离线平台如何实现?
阿里主搜(淘宝天猫搜索)是搜索离线平台非常重要的一个业务,具有数据量大、一对多的表很多、源表的总数多和热点数据等特性。对于将主搜这种逻辑复杂的大数据量应用迁移到搜索离线平台总是不缺少性能的挑战,搜索离线平台经过哪些优化最终实现全量高吞吐、增量低延迟的呢?
348 0
MySQL|主从延迟问题排查(一)
大查询长时间执行无法释放DML读锁,后续同步主库的DDL操作获取DML写锁资源被阻塞等待,导致后续同步主库的操作堆积,主从延迟增长严重。从同步延迟的监控来看,延迟从17:11开始,17:51:59进行kill大查询操作,直到17:53建议业务方将大查询kill掉后才结束。
1757 0
Tomcat 9.0.26 高并发场景下DeadLock问题排查与修复
本文主要针对deadlock问题进行分析以及通过使用Apache提供的新patch进行验证。
1349 0
降低 80% 的读写响应延迟!我们测评了 etcd 3.4 新特性(内含读写发展史)
作者 | 陈洁(墨封)  阿里云开发工程师 导读:etcd 作为 K8s 集群中的存储组件,读写性能方面会受到很多压力,而 etcd 3.4 中的新特性将有效缓解压力,本文将从 etcd 数据读写机制的发展历史着手,深入解读 etcd 3.4 新特性。
1397 0
+关注
袋鼠云
袋鼠云是企业数据化整体解决方案提供商,是数据中台架构倡导者、引领者,通过打通数据供应链,构建企业数据化驱动引擎,加速企业数据化进程,让数据成为企业核心竞争力。
99
文章
2
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载