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

故障发现

核心应用 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 ,可以判断,没有执行事务提交操作,从链路关联的日志中,也能佐证这一点。

相关推荐
小旺不正经23 分钟前
数据库表实现账号池管理
数据库·后端·算法
sanx181 小时前
一站式电竞平台解决方案:数据、直播、源码,助力业务飞速启航
前端·数据库·apache·数据库开发·时序数据库
学IT的周星星1 小时前
《MyBatis变形记:当SQL遇上“智能管家“》
数据库·sql·mybatis
byte轻骑兵1 小时前
突破文档型数据库迁移困境:金仓多模方案破解电子证照系统国产化难题
数据库
xdpcxq10292 小时前
EF Core框架数据库连接管理
java·jvm·数据库
期待のcode3 小时前
MyBatis框架—延迟加载与多级缓存
java·数据库·后端·缓存·mybatis
老华带你飞3 小时前
小区服务|基于Java+vue的小区服务管理系统(源码+数据库+文档)
java·数据库·vue.js·spring boot·论文·毕设·小区服务管理系统
柯南二号3 小时前
【Java后端】MyBatis 和 MyBatis-Plus (MP) 的区别
java·数据库·tomcat
C++chaofan3 小时前
游标查询在对话历史场景下的独特优势
java·前端·javascript·数据库·spring boot
小蒜学长3 小时前
springboot房地产销售管理系统的设计与实现(代码+数据库+LW)
java·数据库·spring boot·后端