生产事故复盘--小问题引发的大事故

事故描述

在6.18日下午五点多，忽然接到通知说后端服务挂了，容器一直重启失败，连忙打开容器云，查看服务状态，抓取最近十分钟的日志，提取日志，发现接口调用日志全部正常，联系平台人员协助处理，排查容器本身问题，并尝试扩展实例个数，保障不影响业务使用。

排查方案

1.分析应用：抓取最近十分钟的日志，发现日志中大量请求信息，基本上都是用户登录或者是查询某个下拉数值（进入某些报表页面的用户较多，且报表筛选框都是使用的下拉查询），分析是否由于用户量激增，导致的http连接过多，影响使用。找到监控指标，发现请求数，请求响应时间正常，请求成功率100%，并无问题。
2.排查数据库：查看数据库，发现数据库连接池数量采用默认的8，但是此时数据库请求量已经达到了200，基本定位到问题出现在数据库层面。

进一步排查

根据数据库连接，定位到应该是某些数据库执行过程中，出现了锁表现象或者是不断重复的慢查询，导致连接没有及时释放，新请求获取不到连接，致使阻塞，且五点正值个别定时任务的执行节点，会有大量的数据库操作，将日志定位到16：59至17：01，进一步查找后发现，在某个一小时执行一次的定时任务中，第一次存在一个data too long 的错误，后面就开始出现了Deadlock found when trying to get lock; try restarting transaction，查看该定时任务的执行代码，发现存在事务回滚操作，由于上面的data too long导致了回滚，当多个事务试图获取某些资源（如表或行的锁）时，发生了循环等待的死锁，导致 MySQL 无法继续执行事务。继续向下查找日志，发现又变成了Lock wait timeout exceeded; try restarting transaction，这表示当前事务正在等待一个行锁或表锁，但在等待超时之后仍无法获取该锁，最后 MySQL 放弃继续等待，抛出该错误。由此，基本定位到问题，找到对应开发负责人，对错误表字段进行修复，并重新确认下事务回滚操作。

个人见解，仅供个人记录。