共计 1521 个字符，预计需要花费 4 分钟才能阅读完成。
一、案例分享
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/
