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

故障发现

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

相关推荐
小草儿79925 分钟前
gbase8s之查看锁表的sql
服务器·数据库·mysql
GoodStudyAndDayDayUp40 分钟前
一个老是用的SQL
java·数据库·sql
whoami-443 分钟前
第二章.数据库与数据库管理系统
数据库·mysql
清风 0011 小时前
一、使用 mdadm 工具在 Ubuntu 上创建 RAID 1(镜像)
运维·服务器·数据库
道斯1 小时前
asp.net老项目运维,出现的问题6之数据库
数据库
zxrhhm1 小时前
Oracle PL/SQL编程中批量数据处理Sparse Collections and SQL%BULK_EXCEPTIONS
数据库·oracle
先睡2 小时前
动态sql
java·数据库·sql
2401_857610033 小时前
剖析 SSM 校园一卡通密钥管理系统 PF 技术架构中安全机制的深度融合
java·数据库·安全
莳花微语3 小时前
Oracle 19c rac 补丁升级,从19.7 to19.22-集群
数据库·oracle