你是否會經常遇到MySQL hang了而不知所措?面對繁雜的callstack信息如何才能快速分析出原因?
本文将通過一個案例,介紹如何快速分析這類問題的方法。
當我們遇到MySQL hang的場景時,大概率是程序内部發生了mutex沖突造成的。這時我們需要在重啟服務前,先搜集callstack信息。
pstack`pidof mysqld` > mysql_callstack
注意:mysqld需要包含符号表
注意:mysqld需要包含符号表
有了callstack信息,我們便可以開始進行分析了。
分析步驟
1. 首先,在callstack日志篩選出每個線程調用inline_mysql_mutex_lock前的函數,以及對應的mutex代碼位置,此處便是線程在等待的mutex。
2. 然後,從該函數向前遍曆每個函數調用,尋找這些函數,看已經成功獲得哪些mutex。
這裡我用腳本對日志進行格式化處理,将每個函數都映射到了github的代碼位置,點擊鍊接可以直接跳轉,使用Chrome浏覽器配合sourcegraph查看代碼也很香。
3. 最後,從日志中回溯每個上鎖函數所對應的前端操作行為,并繪制一張關于線程持有和等待mutex的表格,便能直觀的分析出函數的沖突關系。
總結
由于show binlog logs操作、purge binlog以及從讀取 performance_schema讀取會話變量幾個操作并行發生産生mutex沖突,導緻無法新建連接請求。
最終确認是binlog_transaction_dependency_*變量的讀取需要獲取LOCK_log鎖,此處容易造成死鎖,MySQL 5.7.25 修複了此問題。
關鍵字:愛可生、MySQL數據庫、數據庫運維管理、開源數據庫解決方案
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!