使用观测云排查数据库死锁故障

故障发现

核心应用 pod 发生重启,同时接收到对应使用者反馈业务问题,开始排查。

观测云排查现场

1、根据重启应用信息,查询 APM 执行数据库 update 操作大量报错,执行时间在 5min 以上。

分析 APM 链路异常,发现是触发了数据库的等锁超时,结合数据库等锁超时时间为 5min ,符合预期。

2、查看对应数据库指标,问题时间段等锁耗时、行锁、每秒锁表数据指标异常, 并且在 11:13 分出现死锁。

3、日志关键字搜索"Deadlock",发现有数据库出现死锁,发现 11:13 分有死锁日志。

初步结论

数据库死锁,导致了本次故障发生,需要进一步分析死锁出现的原因。

进一步排查

数据库死锁日志的部分截图。

  • 对比左右两份日志,发现是同一个事务 ID , TRANSACTION 367507261 ,事务持续了 7 分钟。
  • 对应 update 了两个表,左侧执行 update A , 右侧执行了 update B 。
  • 开发排查代码发现, A 表 和 B 表不在一个接口里, 也就是说不可能同时出现在同一个事务中,但数据库日志却得出在一个事务中。问题显得非常诡异。

这里,首先应该确认的一点,数据库事务 ID 是不会出问题的(期间也怀疑过,找 DBA 确认过数据库无问题) ,那极有可能是事务混乱了,应用使用的 spring 框架,使用的是 HikariCP 的数据库连接池,连接池是多线程的,现在假设一种场景,请求 1 使用了一个数据库线程,开启了事务,但是并没有提交事务就结束了,这个线程放回线程池,过了一段时间请求 n 进入直接进入了这个事务, 并开启了子事务进行数据库操作,那么就极有可能发生死锁如下图:

开发复盘整个代码, 发现有代码在 controller 层显示开启了事务,也有显示的提交,但是中间存在逻辑漏洞会直接 return 不关闭事务。

复制代码
##伪代码
method A {
 #开启事务
 transcation.start();
 A = db.select()
 if (A == null) {
    return "数据异常";
 }
 db.update();
 transcation.commit();
 return success;
}

观测云查询作证,确实执行到"查询失败"直接返回到逻辑。 和猜想一致。

对比链路,正常链路会有一个 SELECT, 随后跟一个 UPDATE 。

异常链路中,仅执行了 SELECT ,可以判断,没有执行事务提交操作,从链路关联的日志中,也能佐证这一点。

相关推荐
huazhixuthink18 分钟前
PostgreSQL三种关闭方式的区别
数据库·postgresql
阿里小阿希5 小时前
Vue3 + Element Plus 项目中日期时间处理的最佳实践与数据库设计规范
数据库·设计规范
白鹭6 小时前
MySQL源码部署(rhel7)
数据库·mysql
666和7776 小时前
Struts2 工作总结
java·数据库
还听珊瑚海吗6 小时前
SpringMVC(一)
数据库
星期天要睡觉8 小时前
MySQL 综合练习
数据库·mysql
Y4090018 小时前
数据库基础知识——聚合函数、分组查询
android·数据库
JosieBook9 小时前
【数据库】MySQL 数据库创建存储过程及使用场景详解
数据库·mysql