Oceanbase死锁检测问题

【 使用环境 】 测试环境
【 OB or 其他组件 】OB
【 使用版本 】CE 4.1.0.0
【问题描述】死锁检测开关打开,但是模拟死锁过程中,发现虽然能检测到死锁,但是并不会回滚其中一个会话,另外的一个会话也还是会阻塞
【复现路径】
会话一:
ff61777098cdbbce3c83afef80b7ead4
会话二:
9f5a866543c1aaf6eda608c45bf86454
隐含参数:


【问题现象及影响】

【附件】

1 个赞

蹲答案。

1 个赞

1 个赞

1 个赞

同时输入后,一个事务成功,一个失败,这就不存在两边都在等锁呢。

2 个赞

oceanbase 4.1表锁问题 - 社区问答- OceanBase社区-分布式数据库
可以参考下这个帖子

1 个赞

我这边模拟第二个会话检测到死锁后还是需要手动回滚第一个会话才能自动执行

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

报的这个?

会一直等待,
会话一:
image
会话二:
image

image
你的啥版本

看下你的集群状态都正常不,obd cluster display XXX

image

您好,我是OB死锁检测模块的作者,在4.3版本之前,死锁检测功能还处于不完善的状态(时间和精力投入在其他模块的开发重构上,因而在4.3版本之前没有精力顾及),仅能检测基本的死锁。
在您所遇到的这个场景中,死锁检测应该是正常工作的,而之所以在一个session检测到死锁之后另外一个session没有继续执行,很可能因为您使用的是Oracle模式的租户。

OB工作在Oracle模式下时,探测到死锁后的行为同Oracle保持一致:即只回滚语句,但是不回滚事务,需要用户手动回滚事务。
OB工作在Mysql模式下时,探测到死锁后的行为同Mysql保持一致:即直接回滚事务。

两种行为都是可理解的,Oracle采用了更保守的做法,需要用户去判断,而Mysql采用了更激进的做法,但大多数场景下更符合用户的预期。OB兼容它们的行为。

3 个赞

我这个是MySQL租户的呢,确实检测到了死锁,但是没有回滚

奇怪了,我这测了好几次都没有复现你那问题 :rofl:

我也是试了好几次,都是这样,和你发的不一样,真的奇怪

有毒,哈哈哈,没头绪了,复现不来

1 个赞

复现了多次还是一样的情况

1 个赞

我找上面那个作者看看。

1 个赞

麻烦复现一下,然后将集群日志都压缩传一下