分布式事务数据库HotDB 的死锁检测篇

在分布式事务数据库系统中，若死锁发生在两个数据节点下的存储节点间，MySQL的死锁检测机制将无法检测到死锁。

下面表格中的操作，描述了在分布式系统中，两个数据节点产生死锁的过程。会话一与会话二分别在两个数据节点上执行DELETE操作：


上述情况中，会话一与会话二互相被阻塞，将产生死锁。因是在两个数据节点下的存储节点间，MySQL无法检测到死锁的存在。
在HotDB Server分布式事务数据库系统中，计算节点可检测到多个数据节点下的存储节点间的死锁，并回滚开销最少的事务。

在计算节点的配置文件server.xml中，将死锁检测周期设置为大于0的值，将开启死锁的自动检测功能。默认情况下，死锁检测是开启状态，检测周期为3000ms。

当deadlockCheckPeriod值设置为0时，将不启动死锁检测功能。
在开启计算节点的死锁检测时，再次执行上述的DELETE操作：
会话一，开启事务：

会话二，开启事务：

会话一，在DNID为15的数据节点上执行DELETE语句 ：

会话二，在DNID为13的数据节点上执行DELETE 语句

会话一，在DNID为1 3 的数据节点上执行DELETE语句；DELETE操作将被会话二阻塞：
会话二，在DNID为1 5 的数据节点上执行DELETE语句；此操作将被会话一阻塞；因会话一被会话二阻塞，会话二也被会话一阻塞，此时将产生死锁。

计算节点检测到死锁，回滚了会话一的事务：

注：由于MySQL5.7及以上版本，事务中出现死锁回滚后，不会立即开启新事务。参考官方B UG 链接： https://bugs.mysql.com/bug.php?id=98133 。 HotDB Server针对上述B UG 做了兼容处理：对锁超时、死锁检测、后端连接断开，MySQL5.7及以上版本会根据前端连接autocommit判断是否要开启新事务。