《MySQL所有操作hang住了，怎么破？》要點(diǎn)：

本文介紹了MySQL所有操作hang住了，怎么破？，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者介紹

王松磊,現(xiàn)任職于UCloud,從事MySQL數(shù)據(jù)庫內(nèi)核研發(fā)工作.主要負(fù)責(zé)UCloud云數(shù)據(jù)庫udb的內(nèi)核故障排查工作以及數(shù)據(jù)庫新特性的研發(fā)工作.

系統(tǒng)環(huán)境

CentOS release 6.7

MySQL社區(qū)版MySQL-5.5.24

故障簡述

首先收到故障告警,所有的監(jiān)控?zé)o法讀取到數(shù)據(jù).稍后收到客戶的反饋,無法正常連接數(shù)據(jù)庫.

故障排查

1、嘗試登陸數(shù)據(jù)庫

發(fā)現(xiàn)登陸發(fā)生hang住的情況,無法正常連接.無任何提醒信息報(bào)出.

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

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

2、查看錯(cuò)誤日志

錯(cuò)誤日志完全正常,無任何錯(cuò)誤日志報(bào)出.

3、使用pstack

使用pstack工具查看進(jìn)程內(nèi)各個(gè)線程的堆棧信息.執(zhí)行命令：

shell>pstack ? ?> ?pstack.log

將堆棧日志存放到pstack.log文件中,分析堆棧日志的內(nèi)容.發(fā)現(xiàn)存在很多線程處于等待線程互斥量mutex的狀態(tài),并且等待的mutex是兩個(gè)不同的mutex,猜測是因?yàn)樵创a內(nèi)存在bug,所以造成了進(jìn)程死鎖：

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

而其它新連接或者已經(jīng)連接無應(yīng)答的進(jìn)程,也在等待其中的一個(gè)mutex.

4、使用gdb查看具體信息

執(zhí)行如下命令attach到mysqld進(jìn)程,查看當(dāng)前線程堆棧的具體情況.

shell>gdb -p ?

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

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

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

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

5、查看源碼

根據(jù)gdb調(diào)試中線程2和線程3的信息,查看命令purge binlog和reset master對應(yīng)的源碼.查看發(fā)現(xiàn)兩個(gè)命令對于LOCK_thread_count和LOCK_index調(diào)用順序是不同的.導(dǎo)致同時(shí)執(zhí)行時(shí)會(huì)發(fā)生相互等待,發(fā)生死鎖的情況.

解決問題

通過與客戶溝通,得到確認(rèn),客戶同時(shí)執(zhí)行了purge binlog和reset master命令.最終也確認(rèn)了我們的猜想,由于上述原因?qū)е铝藛栴}的產(chǎn)生.

在查看官方修復(fù)后,發(fā)現(xiàn)該bug已經(jīng)修復(fù).升級到高版本,將客戶數(shù)據(jù)遷移后解決了此問題.

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

總結(jié)

以上是生活随笔為你收集整理的mysql客户端hang_MySQL所有操作hang住了，怎么破？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。