注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

MySQL Shutdown异常处理和分析

MySQL FAQ 彭东稳 3101次浏览 已收录 0个评论

先了解一下MySQL的shutdown流程

1、启动关机过程。

2、如有必要,服务器创建一个关闭线程。

3、服务器将停止接受新连接。

4、服务器终止当前的活动。

5、服务器关机或关闭存储引擎。

6、在服务器退出。

以上只是官方文档中介绍的一些基本的关机流程,正确的关机命令当然是mysqladmin -xx shutdown。接下来,我们来关注一下我们的问题。

mysqladmin shutdown不但没有关闭掉,反而会restart

提示信息如下:

奇了个怪了,我的参数明明是shutdown ,为什么提示信息是restart呢? 错误日志中也无明显错误,程序Bug了?

唯一能关闭的方法就是:kill,这是非法的,我们当然不能这样做。

于是尝试了N种方法

* 可能是/usr/local/mysql/data/xxxx.pid文件没有写的权限

* 可能进程里已经存在mysql进程

* 可能是第二次在机器上安装mysql,有残余数据影响了服务的启动。

* mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件,请打开这个文件查看在[mysqld]节下有没有指定数据目录(datadir)。

* skip-federated字段问题

* 错误日志目录不存在

* selinux惹的祸,如果是centos系统,默认会开启selinux

很不幸的是,都不是上述问题造成。既然google也找不到,那只能看源码了。

大家都知道,mysqld_safe是启动mysql的守护进程,我想89不离10,应该是由它重启的,那就一窥究竟吧。

源码文件如下: mysqld_safe

下面是部分重要的部分,特拿出来分析,其中添加了一些注释和一些方便调试的断点代码(add by keithlan)。

简单描述一下过程就是:myqsld_safe会用eval去启动mysqld,在后台运行,知道接受到kill命令,或者shutdown进程来kill掉它。

如果是非正常kill,mysqld_safe会一直监控,将mysqld进程restart起来。

经过调试后,手动去rm -f 掉pid文件, 然后再mysqladmin shutdown,是可以正常关闭的,很明显,就能定位到问题就出在pid上。为什么mysqladmin进程shutdown的时候没有删除掉pid文件呢?首先可以排除掉权限等问题,因为既然能够create pid,当然可以delete pid咯。问题一定是mysqladmin哪个地方出问题了。果然,根据线索找到mysqladmin代码中断言出现问题Failing assertion: UT_LIST_GET_LEN(rseg->update_undo_list) == 0,网上搜了一堆的bug。后来,想想,是不是表空间出了问题,mysql shutdown的时候会去回收表空间记录,如果回收不成功,导致不能normal shutdown,导致无法删除掉pid文件。 于是,将表空间重建后,问题消失。

表空间重建实战(独立表空间)

1)创建环境

2)备份DB

3)db所在的目录情况

5)查看所有的db

6)删除掉占用空间的

7)停止MySQL

8)删除innodb相关文件

9)启动MySQL

此时文件重新生成了

10)进入查询下MySQL是否正常

11)建库、重新导入

数据都正常

理想很美好,现实就是mysql库中有些表由于表空间文件不存在了,所以有问题。

PS:这个表空间文件重建只是一个理想状态,如果数据导不出来的话,删除表空间文件就会造成表数据无法正常读取的。

原文出处:http://keithlan.github.io/2015/07/14/mysql_shutdown_err/


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (0)or分享 (0)
关于作者:

您必须 登录 才能发表评论!