《MySQL所有操作hang住了，怎么破？》要點：
本文介紹了MySQL所有操作hang住了，怎么破？，希望對您有用。如果有疑問，可以聯系我們。

作者介紹

王松磊,現任職于UCloud,從事MySQL數據庫內核研發工作.主要負責UCloud云數據庫udb的內核故障排查工作以及數據庫新特性的研發工作.

系統環境

CentOS release 6.7

MySQL社區版MySQL-5.5.24

故障簡述

首先收到故障告警,所有的監控無法讀取到數據.稍后收到客戶的反饋,無法正常連接數據庫.

故障排查

1、嘗試登陸數據庫

發現登陸發生hang住的情況,無法正常連接.無任何提醒信息報出.

shell>mysql -h192.168.150.21 -P50001 -uabc -pabc

shell>mysql ?-S?/var/lib/mysql/mysql.sock??-uabc -pabc

2、查看錯誤日志

錯誤日志完全正常,無任何錯誤日志報出.

3、使用pstack

使用pstack工具查看進程內各個線程的堆棧信息.執行命令：

shell>pstack ?<mysqld ?pid> ?> ?pstack.log

將堆棧日志存放到pstack.log文件中,分析堆棧日志的內容.發現存在很多線程處于等待線程互斥量mutex的狀態,并且等待的mutex是兩個不同的mutex,猜測是因為源碼內存在bug,所以造成了進程死鎖：

其中線程2和線程3分別在等待不同的mutex.

而其它新連接或者已經連接無應答的進程,也在等待其中的一個mutex.

4、使用gdb查看具體信息

執行如下命令attach到mysqld進程,查看當前線程堆棧的具體情況.

shell>gdb -p ?<mysqld ?pid>

執行命令info thread查看線程的具體信息,發現很多線程均在等待鎖信息.通過上面描述的pstack日志信息,我們知道線程2和線程3存在等待不同鎖的行為且可疑性比較高.

切換到線程2查看,線程在等待的mutex為LOCK_index.

切換到線程3查看,線程在等待的mutex為LOCK_thread_count.

由此猜測,是源碼中由于存在LOCK_index和LOCK_thread_count相互等待的BUG,導致兩個mutex均未被釋放,從而發生死鎖情況.其它需要獲得鎖的操作均發生一致等待的情況(即發生hang住).

5、查看源碼

根據gdb調試中線程2和線程3的信息,查看命令purge binlog和reset master對應的源碼.查看發現兩個命令對于LOCK_thread_count和LOCK_index調用順序是不同的.導致同時執行時會發生相互等待,發生死鎖的情況.

解決問題

通過與客戶溝通,得到確認,客戶同時執行了purge binlog和reset master命令.最終也確認了我們的猜想,由于上述原因導致了問題的產生.

在查看官方修復后,發現該bug已經修復.升級到高版本,將客戶數據遷移后解決了此問題.

文章來自微信公眾號：DBAplus社群

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4113.html