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

培训中心
#1

【产品名称】 OceanBase

【产品版本】 3.2版本

【问题描述】

OceanBase 企业版3.2 正式发布！ AP性能提升6倍，更硬核的HTAP - 官方发布 - 社区问答- OceanBase社区-分布式数据库

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

问题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，这个论文后来有发新版本吗？我没有找到？求推荐。谢谢


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


1 个赞
#4

谢谢