MySQL 5.6的一个bug引发的故障
2017-08-04 13:59
323 查看
突然收到告警,提示mysql宕机了,该服务器是从库。于是尝试登录服务器看看能否登录,发现可以登录,查看mysql进程也存在,尝试登录提示
最大连接数设置的3000,怎么会连接数不够了呢。于是使用gdb修改一下最大连接数:
修改以后可以登录了,于是show processlist看看是啥情况:
发现监控程序执行show slave status都被卡住了,最后把最大连接数用完,导致Too many connections。复制卡在了Waiting for commit lock。查阅资料以后发现是触发了bug。https://bugs.mysql.com/bug.php?id=70307,改bug在5.6.23已经修复。我的版本是 5.6.17
可以看到在凌晨2点左右的时候卡住的,突然发现凌晨2点这个时候正是xtrabackup备份数据的时间。xtrabackup备份的时候执行flushs tables with read lock和show slave status会有可能和SQL Thread形成死锁,导致SQL Thread一直被卡主。原因是SQL Thread的DML操作完成之后,持有rli->data_lock锁,commit的时候等待MDL_COMMIT,而flush tables with read lock之后执行的show slave status会等待rli->data_lock;修复方法是rli->data_lock锁周期只在DML操作期间持有。
stop slave没有用,正常停止没有用,最后只能kill -9,问题还是比较严重的,解决的方法就是升级新版本。
ERROR 1040 (HY000): Too many connections
最大连接数设置的3000,怎么会连接数不够了呢。于是使用gdb修改一下最大连接数:
gdb -p $(cat pid_mysql.pid) -ex "set max_connections=5000" -batch
修改以后可以登录了,于是show processlist看看是啥情况:
发现监控程序执行show slave status都被卡住了,最后把最大连接数用完,导致Too many connections。复制卡在了Waiting for commit lock。查阅资料以后发现是触发了bug。https://bugs.mysql.com/bug.php?id=70307,改bug在5.6.23已经修复。我的版本是 5.6.17
mysql> SELECT a.trx_id, trx_state, trx_started, b.id AS thread_id, b.info, b.user, b.host, b.db, b.command, b.state FROM information_schema.`INNODB_TRX` a, information_schema.`PROCESSLI ST` b WHERE a.trx_mysql_thread_id = b.id ORDER BY a.trx_started; +----------+-----------+---------------------+-----------+------+-------------+------+------+---------+-------------------------+ | trx_id | trx_state | trx_started | thread_id | info | user | host | db | command | state | +----------+-----------+---------------------+-----------+------+-------------+------+------+---------+-------------------------+ | 51455154 | RUNNING | 2017-08-02 02:20:07 | 6404 | NULL | system user | | NULL | Connect | Waiting for commit lock | +----------+-----------+---------------------+-----------+------+-------------+------+------+---------+-------------------------+ 1 row in set (0.03 sec)
可以看到在凌晨2点左右的时候卡住的,突然发现凌晨2点这个时候正是xtrabackup备份数据的时间。xtrabackup备份的时候执行flushs tables with read lock和show slave status会有可能和SQL Thread形成死锁,导致SQL Thread一直被卡主。原因是SQL Thread的DML操作完成之后,持有rli->data_lock锁,commit的时候等待MDL_COMMIT,而flush tables with read lock之后执行的show slave status会等待rli->data_lock;修复方法是rli->data_lock锁周期只在DML操作期间持有。
stop slave没有用,正常停止没有用,最后只能kill -9,问题还是比较严重的,解决的方法就是升级新版本。
相关文章推荐
- 故障案例--mariadb 10.0向mysql5.6官方版本迁移的一个坑
- 一个存在三年的内核 bug 引发大量的容器系统出现网络故障
- 一个存在三年的内核 bug 引发大量的容器系统出现网络故障
- 一个Php的Xml库的Bug引发的血案
- 一个回车引发的Bug
- 一个MySQL-JDBC驱动bug引起的血案……
- MySQL源码:Innodb两次写与多实例buffer pool的一个BUG的说明与解决
- Win2012R2的一个Bug---安装群集后可能引发的软件崩溃问题及相应补丁
- 一个bug引发的“血案”
- Nutch学习笔记10---一个bug引发Http协议研究
- mysql删除数据库文件ibdata1后引发的故障
- MySQL关于timestamp和mysqldump的一个“bug”【转】
- 记一个WINDOWS命令行引发的BUG
- 6.3.1版mysql.data.dll的一个Bug
- 通过View.post()获取View的宽高引发的两个问题:1post的Runnable何时被执行,2为何View需要layout两次;以及发现Android的一个小bug
- 一个实习生名额引发的bug
- mysql一个冷门参数引起的同步故障
- Mysql备份还原的一个bug
- 记一个mysql-connector-java包的bug
- 提供一个MySQL 5.6版本适合在1GB内存VPS上的my.cnf配置文件: