3.2版本对死锁检测理解的问题

【产品名称】 OceanBase


【产品版本】 3.2版本


【问题描述】

https://open.oceanbase.com/ask/detail?id=13700131&search=%E6%AD%BB%E9%94%81%E6%A3%80%E6%B5%8B&pageNum=1
1、新增全局死锁检测功能,及时识别处理死锁问题,保障事务执行的稳定性死锁是数据库非常常见的问题。出现死锁时,需要DBA来监控或巡检发现,并人工进行处理;定位时间和周期都比较长。针对这一场景,OceanBase数据库在V3.2版本支持全局死锁检测功能。实现分布式死锁检测的关键在于, 如何汇总每个节点上的局部锁等待关系, 并基于汇总出来的全局锁等待关系产生全局的锁等待图(wait-for graph), 找出图中成环(deadlock cycle)的事务, 最后挑选出最优的事务作为牺牲者(victim)去解开死锁。OceanBase数据库采用基于Mitchell-Merritt算法,使得分布式死锁检测在分布式数据库系统中的得以实现。目前死锁检测范围已包含嵌套执行、存储过程、触发器、外键等,后续版本也会持续增强和完善全局死锁检测能力。

没有理解上述描述,我理解,有两处冲突的地方:

  1. OB使用了全局死锁检测,是说使用了“全局死锁检测的算法”吗?如果是的话,Mitchell-Merritt算法 并不是“全局的死锁检测”的分类啊,它应该是分布式死锁检测的分类吧。
  2. Mitchell-Merritt算法 属于“single-source mode” 分类,也就是说,一个事物可以发出outstanding 请求行锁的数量最大只能是1。

        a) OB作为分布式数据库,如果OB的一个事物的outstanding 请求锁数量最大只有1的话,效率是不是低了点?

        b) 如果OB的outstanding 请求锁数量最大超过1,又使用Mitchell-Merritt,那么就不符合算法描述的约束条件了,那么可能有progress的问题(有死锁,但是找不出来)。

        c) 还有一个猜测,OB改造了Mitchell-Merritt算法,这样的话,就不能说是Mitchell-Merritt算法了吧,毕竟这个算法有完整的证明过程,改造过的算法需要自己想办法证明了。



理解有误,请专家帮助指正,谢谢。


问题2.a, 进一步,下图来自Mitchell-Merritt论文,如果一个事物A在T0事件,等待事物B的时候,满足下图的条件。但是,在T1事件,事务A需要等待事物C,那么不满足这个条件,无法使用下图的Block做状态转换。我理解对吗?我看的是论文《A Distributed Algorithm for Deadlock Detection and Resolution》Don P. Mitchell † Michael J. Merritt † AT&T Bell Laboratories,这个论文后来有发新版本吗?我没有找到?求推荐。谢谢


  • OB使用了全局死锁检测,是说使用了“全局死锁检测的算法”吗?如果是的话,Mitchell-Merritt算法 并不是“全局的死锁检测”的分类啊,它应该是分布式死锁检测的分类吧。
  • 是的, 属于分布式死锁检测
  • Mitchell-Merritt算法 属于“single-source mode” 分类,也就是说,一个事物可以发出outstanding 请求行锁的数量最大只能是1。
  • 我们改造了对应的算法, 并在之后会有对应的论文发布, 在论文发布以前, 我们可能无法直接透露其中的细节, 但我们在论文发布后会及时公布, 敬请期待


1 个赞

谢谢