一、案例分享
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/