《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社群