MySQL · 答疑解惑 · 物理备份死锁分析

本文对 5.6 主备场景下，在备库做物理备份遇到死锁的case进行分析，希望对大家有所帮助。

这里用的的物理备份工具是 percona-xtrabackup(pxb)，有的同学可能不清楚其备份流程，所以这里先简单说下，pxb的备份步骤是这样的：

拷贝 innodb redo log，这是一个单独的线程在拷，直到备份结束；

拷贝所有innodb ibd文件；

加全局读锁，执行 flush tables with read lock(ftwrl);

拷贝 frm、myd、myi 等文件；

获取位点信息，执行 show slave status 和 show master status；

解锁，unlock tables;

做一些收尾处理，备份结束。

如果 myisam 表很多话，全局读锁的持有时间会比较长，所以一般都在备库做备份。

我们先看一下死锁时的现场是怎样的：

可以看到 show slave status 被堵了很久，另外 sql 线程在 waiting for commit lock，说明在等待 commit 锁。

这时候如果我们再连接进去执行 show slave status 也会被堵，并且即使 ctrl-c kill 掉线程，线程依然还在。

pstack 看下相关线程的 backtrace，show slave status 线程的 backtrace 如下，非常明显是在等mutex，对应代码为 <code>mysql_mutex_lock(&amp;mi-&gt;rli-&gt;data_lock)</code>:

sql 线程的 backtrace 如下，在等 commit 锁：

如果我们gdb进去，去调试sql线程，在 <code>mdl_context::acquire_lock</code>中：

可以看到 commit 锁被线程 1 持有。

sql线程在 <code>xid_log_event::do_commit</code> 之前会持有 <code>rli_ptr-&gt;data_lock</code>。

所以现在就清楚了，是线程1（备份线程）和线程3（sql线程）死锁了，还原下死锁过程：

备份线程执行 ftwrl，拿到 commit 锁；

sql线程执行到xid event，准备提交事务，请求 commit 锁，被备份线程阻塞；

备份线程为了获取 slave 执行位点，执行 show slave status，需要获取 <code>rli-&gt;data_lock</code>，被 sql 线程阻塞。

就这样2个线程互相持有等待，形成死锁。

我们知道，mdl 是有死锁检测的，为什么这里没有检测到呢？因为<code>rli-&gt;data_lock</code>是一个mutex，不属于mdl系统的，在这个死锁场景中，mdl锁系统只能检测到对 commit 锁的请求，是不存在死锁的。

之后的 show slave status 都被堵，是因为在执行 show slave status 前，会请求一个mutex:

之前死锁的 show slave status 没有退出，后面的 show slave status 自然堵在这个 mutex 上，并且因为无法检测 <code>thd-&gt;killed</code>，所以一直无法退出。

在上面的bug修复后，又出现了死锁，但死锁的情况却不一样，show processlist 结果如下：

依然是 sql 线程在等待commit锁，然后 show slave status 被堵住没有返回，不同的是多了一个 stop slave; 我们来看下 stop slave 的backtrace:

对应代码，可以发现 stop slave 正在等待 sql 线程退出，而sql线程此时正在等待备份线程（id=6）持有的 commit 锁。整个死锁过程是这样的：

用户执行 stop slave，准备停掉备库复制线程，等待 sql 线程退出；

备份线程为了获取 slave 执行位点，执行 show slave status，需要获取 <code>lock_active_mi</code> 锁，被用户线程（stop slave）阻塞。

这次是备份线程、sql 线程、用户线程3个线程互相持有等待，形成死锁。

这次并不是代码bug，算是一个用法问题，因此我们在运维过程中，如果发现 sql 线程在 waiting for commit lock，就不要 stop slave。

如果不可避免出现了死锁，该怎么解决呢？

通过上面的分析可以看到，不管是在 case 1 还是 case 2，备份线程和用户线程都不再接受响应了，要解决死锁的话，只能 kill 掉 sql 线程了，那么直接 kill 是否有风险呢？

如果你使用的 mysql 版本已经修掉这个bug，也就是在 5.6.21 版本及之后，那么 kill sql 线程是安全的。

如果为了测试或研究代码，要想复现死锁该怎么办呢？如果直接在备库执行一个 ftwrl，很可能是复现不了的，因为ftwrl是获取2个锁，全局读锁和全局 commit 锁，sql 线程非常可能被全局读锁堵到（waiting for global read lock），而不是被 commit 锁堵（waiting for commit lock）。

一种方法是写 testcase，用 dubug sync 功能设置同步点，让线程停在指定的地方，但这要求 mysqld 跑在deubg模式下，并且要求有一定的mysql 源码开发基础；

另一种方法是改代码，延长<code>do_commit</code>的时间，比如 sleep 一段时间，这样就给我们足够的时间让 ftwrl 在 sql 线程请求 commit 锁前执行完成，但是这需改代码，然后重新编译安装；

systemtap 起初只支持在内核空间进行探测，0.6 版本之后可以在用户空间进行探测，使用 systemtap 需要程序中包含 debug 信息（程序编译时加上 -g 选项）。

列出所有我们可以对 mysqld 进行探测的地方。

列出所有可以对 <code>xid_log_event</code> 类进行探测的地方。

如果我们想让 <code>xid_log_event::do_commit</code> 执行有点延迟，可以这样做：

16011 是正在跑的备库进程pid，执行上面的 stap 命令后，每当备库执行到 <code>xid_log_event::do_commit</code> 时，stap 就会打出个 “got it”，然后 sql 线程暂停3s，这就给了我们充足的时间去执行 ftwrl，在sql线程 commit 前拿到 commit 锁。