mysql主从复制线程死锁_MySQL Bug剖析之Slave节点并行复制死锁

此文已由作者温正湖授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

有天一早，DBA同学就找上来了，说有个DDB集群下的RDS实例Slave节点(从库)死锁了，请求支援。说实话，一大早就遇到死锁这种棘手的问题，我的内心是奔溃的。不过万幸的是，DBA说这个实例还未正式上线，处于上线前压测阶段。这么一来，至少现场可以一直保持着。方便定位问题。那么，是什么问题呢，不卖关子，直接上图：

这是show processlist的结果。可以看到有一大坨的连接，基本上都是权限操作相关的语句，全都卡在“waiting for table level lock”上。还有几个复制管理操作，比如stop slave，也卡住了。这密密麻麻一大堆，看得都烦。还是得从这些连接里面挖掘出少数有用的信息。所以登上实例的mysql客户端捋下才是王道。先看看有没有锁相关的直接信息：

show engine innodb status\G

------------

TRANSACTIONS

------------

Trx id counter 6506046

Purge done for trx's n:o 

History list length 2057

LIST OF TRANSACTIONS FOR EACH SESSION:

---TRANSACTION 421794207149728, not started

0 lock struct(s), heap size 1136, 0 row lock(s)

---TRANSACTION 421794207150640, not started

里面根本就没有持锁相关的提示，而且事务全都处于not started状态。再看看InnoDB锁相关表：

mysql> select * from information_schema.INNODB_LOCK_WAITS;

Empty set (0.00 sec)

mysql>

mysql> select * from  information_schema.INNODB_LOCKS;

Empty set (0.00 sec)

还是空空如也。既然这样，那直接看这些连接吧。理一理先后顺序，发现有3个连接是最早同时被卡主的：

|  284480 | system user |           | dbn3               | Connect | 60771 |             0 | Waiting for table leve