MySQL redo死锁问题排查及解决过程分析

问题背景

周一上班，首先向同事了解了一下上周的测试情况，被告知在多实例场景下 MySQL Server hang 住，无法测试下去，原生版本不存在这个问题，而新版本上出现了这个问题，不禁心头一颤，心中不禁感到奇怪，还好现场环境还在，为排查问题提供了一个好的环境，随即便投入到紧张的问题排查过程当中。问题实例表现如下：

首先，通过 pstack 工具获取当前问题实例的堆栈信息以便后面具体线程的查找 & 问题线程的定位：

使用 pt-pmp 工具统计 hang.info 中的进程信息，如下：

问题分析

从堆栈上可以看出，有这样几类线程：

等待进入 INNODB engine 层的用户线程，测试环境中 innodb_thread_concurrency=16， 当 INNODB 层中的活跃线程数目大于此值时则需要排队，所以会有大量的排队线程，这个参数的影响&作用本身就是一篇很不错的文章，由于篇幅有限，在此不做扩展，感兴趣者可以参考官方文档：14.14 InnoDB Startup Options and System Variables；
操作过程中需要写 redo log 的后台线程，主要包括 page cleaner 线程、异步 io threads等；
正在读取Page页面的 purge 线程 & 操作 change buffer 的 master thread；
大量的需要写 redo log 的用户线程。
从以上的分类不难看出，所有需要写 redo log 的线程都在等待 log_sys->mutex，那么这个保护 redo log buffer 的 mutex 被究竟被哪个线程获取了呢，因此，我们可以顺着这个线索进行问题排查，需要解决以下问题：

问题一：哪个线程获取了 log_sys->mutex ？
问题二：获取 log_sys->mutex 的线程为什么没有继续执行下去，是在等其它锁还是其它原因？