mysql客户端hang_MySQL所有操作hang住了,怎么破?
《MySQL所有操作hang住了,怎么破?》要點(diǎn):
本文介紹了MySQL所有操作hang住了,怎么破?,希望對(duì)您有用。如果有疑問,可以聯(lián)系我們。
作者介紹
王松磊,現(xiàn)任職于UCloud,從事MySQL數(shù)據(jù)庫(kù)內(nèi)核研發(fā)工作.主要負(fù)責(zé)UCloud云數(shù)據(jù)庫(kù)udb的內(nèi)核故障排查工作以及數(shù)據(jù)庫(kù)新特性的研發(fā)工作.
系統(tǒng)環(huán)境
CentOS release 6.7
MySQL社區(qū)版MySQL-5.5.24
故障簡(jiǎn)述
首先收到故障告警,所有的監(jiān)控?zé)o法讀取到數(shù)據(jù).稍后收到客戶的反饋,無法正常連接數(shù)據(jù)庫(kù).
故障排查
1、嘗試登陸數(shù)據(jù)庫(kù)
發(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,猜測(cè)是因?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為L(zhǎng)OCK_index.
切換到線程3查看,線程在等待的mutex為L(zhǎng)OCK_thread_count.
由此猜測(cè),是源碼中由于存在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對(duì)應(yīng)的源碼.查看發(fā)現(xiàn)兩個(gè)命令對(duì)于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ù).升級(jí)到高版本,將客戶數(shù)據(jù)遷移后解決了此問題.
文章來自微信公眾號(hào):DBAplus社群
總結(jié)
以上是生活随笔為你收集整理的mysql客户端hang_MySQL所有操作hang住了,怎么破?的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: unity json mysql_uni
- 下一篇: mysql删除表命令语句_MySQL增删