問題背景

周一上班，首先向同事了解了一下上周的測試情況，被告知在多實例場景下 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 的線程為什么沒有繼續執行下去，是在等其它鎖還是其它原因？