MySQL升级WRITE_SET后的一次死锁分析

背景

MySQL在推出MGR的时候使用了WRITE_SET， 借用这个思想， MySQL在5.7.22版本引入了基于WRITE_SET的并行复制方案[1]。在原先的主从复制技术中，同一批次的事物能进入事物的prepare阶段说明那批事物没有冲突，所以可以并发执行。我们都知道innodb是基于行锁的数据库，所以如果能够按照行级别的粒度来并发的回放数据会对性能有很大的提高。采用这套方案的性能优点就有很多方面了，其中一个可以简单看到的好处就是：我们在回放的时候就不用依赖于主上事物提交的情况了，正所谓less is more。减少了依赖，并行从宏观上也能按照逻辑行这样的来回放，所以性能肯定有很大的提升[2]. 故而，我们数据库这边在一些实例上启用了这个并行回放特性。

导致我们死锁的现象是： 我们发现开启了write_set并行回放的实例从库上死锁的概率比以前高了不少， 并且发生死锁的实例都是在进行xtrabackup备份。本文主要分析这些数据库实例上发生死锁的原因。

场景

我们知道MySQL事物会设计到很多的锁,比如MDL锁，innodb的行锁，意向锁，latch
锁等等。不同的隔离级别锁的行为也有很多的差异。从死锁理论的角度：死锁就是有向图中存在环，从而造成相互等待。要解决死锁只要简单的破坏任何一条边，来打破环行等待。当然实际的实现可能会因各个环节点的权重不同而有所优化，选择代价最小的。但之前的重点肯定是找出这个“环”。而这些锁有些是运维的时候可以看到有些是看不到的。比如latch锁一般对用户看不到。因为性能原因，我们的MDL锁和INNODB锁的详细信息并未收集。如果开启了，就可以通过performance_schema.metadata_lock这个表来查询MDL锁的相关信息，通过show engine innodb status来查看详细innodb的加锁信息。

通过简单的分析，我们锁定是MDL死锁。所以在这样的场景下，我们只能通过show full processlist来查看到当时的状态，如下图：

case1:

图1

case2:

图2-1