一个罕见的MySQL redo死锁问题排查及解决过程

《一个罕见的MySQL redo死锁问题排查及解决过程》要点：
本文介绍了一个罕见的MySQL redo死锁问题排查及解决过程，希望对您有用。如果有疑问，可以联系我们。

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

• 并发量为 384 的时候出现的问题；
• MySQL 服务器无法执行事务相关的语句,即使简单的 select 语句也无法执行；
• 所有线程处于等待状态,无法 KILL.

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

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

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

• 等待进入 INNODB engine 层的用户线程,测试环境中 innodb_thread_concurrency=16,当 INNODB 层中的活跃线程数目大于此值时则需要排队,所以会有大量的排队线程,这个参数的影响&作用本身就是一篇很不错的文章,由于篇幅有限,在此不做扩展,感兴趣者可以参考官方文档：https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_thread_concurrency；
• 操作过程中需要写 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 的线程为什么没有继续执行下去,是在等其它锁还是其它原因?
• 问题三：如果不是硬件问题,整个资源竟争的过程是如何的?

在查找 log_sys->mutex 所属线程情况时,有两点可以帮助我们快速的定位到这个线程：

• 由于 log_sys->mutex 同时只能被同一个线程获得,所以在 pt-pmp 的信息输出中就可以排除线程数目大于1的线程；
• 此线程既然已经获取了 log_sys->mutex,那就应该还是在写日志的过程中,因此重点可以查看写日志的逻辑,即包括：mtr_log_reserve_and_write 或 log_write_up_to 的堆栈.

顺着上面的思路很快的从 pstack 中找到了以下线程：

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!