记OceanBase死锁超时

祈雨的笔记

安全多方计算MPC spark原理解析 kueue执行源码分析 spark on k8s执行源码分析 spark-operator源码解析系统压测遇到的缓存击穿问题我的世界PC与安卓联机蚂蚁金服流量投放平台的AIG改造 G1大对象致Old区占用率高日志打印导致接口响应率下跌分析 Groovy加载类导致OOM分析 ERROR日志打印导致CPU满载应用发版期间服务响应超时 Ark Serverless初探系统优化复盘一二三 The user specified as a definer does not exist Kong网关初探 API网关选型调研 CPU火焰图常用工具配置中心选型调研 root操作Nginx导致用户组错误基于Proxifier使用代理 FastJSON字段智能匹配踩坑 Nacos初探记一次Nginx服务器CPU满荷载故障基于券系统分库分表的思考 limit不参与SQL成本计算致索引失效 Linux常用性能监控命令 golang低版本http2偶现400 hostname in certificate didn't match 常见对称加密原理以及应用 tcp_tw_recycle引起的TCP握手失败记一次mysql执行DDL导致锁表 mysql磁盘占用查看 mysql对text字段update致磁盘增长 elasticsearch报错index read-only TIME_WAIT与Http的Keep-Alive 记一次TIME_WAIT导致连接数报警记一次生产事故OOM问题排查 redis分布式锁RedissonLock的实现细节 webservice复杂加密签名(2)java调用 webservice复杂加密签名(1)SoapUI mysql延时关联利用中间人拦截实现APP内H5窜改 MySQL表字符集不同导致关联查询索引失效通过SSH隧道远程办公数据落盘方案 BeanDefinitionRegistryPostProcessor扩展 mysql空间索引 HTTPS攻击 spring循环依赖过程解析 elasticsearch性能优化 mysql IS NULL 使用索引 mysql字符集utf8mb4失效踩坑常用加密算法 xml与javaBean转换初探InnoDB MVCC源码实现 mysql索引原理 redis之list源码分析 redis之key过期源码分析 redis之string源码分析 redis之hash源码分析线程池之ThreadPoolExecutor mysql数据页结构 Using temporary与Using filesort mysql回表致索引失效 springboot(28)HTTP连接池定时任务之ScheduledThreadPoolExecutor elasticsearch常用script聚合 elasticsearch实现like查询 elasticsearch实现乐观锁 elasticsearch准实时原理 springboot(27)自定义缓存读写机制CachingConfigurerSupport optimizer tracing arthas常用命令 HTTP和HTTPS详解 redis集群选举机制 kafka消息重试一点压力测试的经验 kafka架构概念 explain分析sql语句字段的解释 JVM问题分析处理手册 logstash过滤器(2)date logstash过滤器(3)dissect logstash编码器(1)json logstash编码器(2)multiline logstash表达式 logstash输入(1)通用选项 logstash输入(3)file logstash过滤器(1)通用选项 logstash输入(2)stdin logstash安装记一次前端vConsole导致JSON序列化错误排查解决多个异步操作嵌套问题 fastjson反序列化失败autoType is not support RTMP串流服务 POI自动调整列宽错误 Nginx+Lua实现动态黑名单使用curl命令模拟POST和GET请求 ResponseEntity下载文件

记OceanBase死锁超时

祈雨的笔记 · 2021-08-15 · via 祈雨的笔记

背景

线上环境大促活动期间内容平台偶发数据库连接报错，报错信息为 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure ，初步以为是数据库的其他租户给数据库服务器压力大，导致服务端异常断开了内容平台的数据库连接，因此把这个异常当做数据库服务器不稳定直接忽略了。但后续大促活动已经过去，依然偶发会报同样的异常，这才意识到该异常也许不是数据库服务器不稳定导致。

分析

问题排查

查看应用监控和错误日志后发现，每次偶发报错时，必然会同时至少有两个数据库连接异常。抽样一次报错信息如下：

节点1报错日志：

2021-08-09 10:16:55,062 ERROR biz handle exception:
### Error querying database.  Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 5,001 milliseconds ago.  The last packet sent successfully to the server was 5,001 milliseconds ago.
### The error may exist in xml
### The error may involve defaultParameterMap
### The error occurred while setting parameters
### SQL: select     id     from table     where id =?     for update
### Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

节点2报错日志：

2021-08-09 10:16:55,071 ERROR biz handle exception:
### Error querying database.  Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 5,003 milliseconds ago.  The last packet sent successfully to the server was 5,003 milliseconds ago.
### The error may exist in xml
### The error may involve defaultParameterMap
### The error occurred while setting parameters
### SQL: select     id     from table     where id =?     for update
### Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

所有的报错连接均执行的同一个sql语句select id from table where id =? for update ，其业务场景如下所示：当外部系统请求内容平台批量保存记录时，内容平台在同一个事务中对所有的记录依次先上锁，再更新保存记录。根据错误信息显然是记录上锁超时，导致连接超时异常中断。

进一步去日志中翻找等待锁超时的具体SQL语句，尝试分析两个报错数据库连接事务期间，分别对哪些记录上锁成功，又再哪条记录等待锁超时。

节点1等待锁超时的报错SQL：

[2021-08-09 10:16:55.056483] WARN Slow transaction, last_sql=select
    id
    from table
    where id ='593'
    for update)

而该事务中依次上锁的记录ID如下

1 2	select id from table where id ='402' for update select id from table where id ='593' for update

节点2等待锁超时的报错SQL：

[2021-08-09 10:16:55.061845] WARN Slow transaction, last_sql=select
    id
    from table
    where id ='402'
    for update)

而该事务中依次上锁的记录ID如下

1
2
3

select id from table where id ='593' for update
select id from table where id ='469' for update
select id from table where id ='402' for update

根据以上信息，可得两个连接事务对每条记录的上锁流程，如下表。显然是两个事务发生了死锁，事务1等待事务2，事务2等待事务1。但问题又来了，死锁为什么会导致连接超时报错？例如mysql的锁存在超时检查和主动检查，当出现两个事务相互等待锁而导致死锁时，直接通过主动检查而中断其中一个事务，而不用傻傻等待两个事务都超时失败，初步推测是OceanBase不支持死锁的主动检查能力。

-	事务1	事务2
步骤1	`402`上锁成功
步骤2		`593`上锁成功
步骤3	`593`等待锁
步骤4		`469`上锁成功
步骤5		`402`等待锁
步骤6	超时报错	超时报错

问题复现

OceanBase死锁

-	事务1	事务2
步骤1	`c1`上锁成功
步骤2		`c2`上锁成功
步骤3	`c2`等待锁
步骤4		`c1`等待锁
步骤5	锁等待超时，事务中断，释放所有锁	锁等待超时，事务中断，释放所有锁

实测发现OceanBase的锁判断只有超时判断，没有死锁的主动检查。因此多个事务之间发生死锁时，客户端抛出来的异常是超时异常，而不是死锁异常。

mysql死锁

再看看MySQL发生死锁的处理逻辑，当多个事务之间死锁后，MySQL通过死锁主动检查立即检测出锁资源的相互依赖问题，然后直接中断锁等待最久的事务从而释放该事务的锁资源，解决死锁问题。

-	事务1	事务2
步骤1	`c1`上锁成功
步骤2		`c2`上锁成功
步骤3	`c2`等待锁
步骤4		`c1`等待锁
步骤5	主动检查判断死锁，事务中断，释放所有锁
步骤6		`c1`上锁成功

解决

解决上述问题中的偶发超时问题，实际上就是要避免多个事务之间出现死锁。方案如下：

批量加锁
固定加锁顺序

方案一

方案一是将原先多条记录依次上锁修改成一次性给依赖的资源全部上锁，改写如下。

1
2
3

select id from table where id ='c1' for update
select id from table where id ='c2' for update
select id from table where id ='c3' for update

1	select id from table where id in ('c1','c2','c3') for update

方案二

死锁的原因是因为多个事务之间出现锁依赖循环，因此在上锁前，对等待上锁记录进行排序，即固定加锁顺序，从而解决死锁问题。

该方案修改成本最低，因此最终选择了该方案作为最终解决方案。

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

祈雨的笔记

背景

分析

问题排查

问题复现

OceanBase死锁

mysql死锁

解决

方案一

方案二