数据库监控断点业务中断的一种案例及分析

客户问题

发现CPU监控断点，大约持续6~7分钟，期间业务不可访问

CPU监控断点

分析定位

我们从实例监控图可以看出

实例监控图

• CPU使用率从中断到超出100%
• threads_connected和threads_running飙升
• 慢查询也有突增

其中有些是现象，有些是原因，线程数增高的原因是什么，很明显是某些语句阻塞了后续的请求，导致请求堆积，连接线程数和运行线程数突增，导致CPU利用率飙升，进而导致监控上报agent异常，当这个罪魁祸首SQL执行完毕之后，后续请求会得到顺畅执行，实例状态会恢复

问题解决

问题已经分析出来了，就是某个SQL阻塞了其他请求，那么如何找到这条SQL呢？有两种方式

1. 抓现场，故障时间点执行show processlist,观察下当前SQL会话的情况，并且select * from information_schema.innodb_trx;
2. 事后查日志，从上面监控图可以看出本次罪魁祸首SQL执行完毕的时刻，记录了大量慢查询，那么我们大胆推测，一定有一个SQL锁表时长约在6~7分钟，我们从慢日志中找出即可

由于本次是事后分析，因此采用查慢日志的方式

慢日志

从上图可以看出，查询时间411s的语句就是锁表的语句，是本次监控断点的原因

tips:大量prepare的原因是因为同一时刻执行了大量其他SQL，由于和长时间执行的那条SQL存在冲突，导致只记录了prepare状态，SQL并未执行

image.png

规避措施

优化慢SQL，解决锁冲突