不能轻视的MySQL重启过程

数据库的重启看似是一件非常简单,没有技术含量的活,这是我以前说的话。而这句话简直是戳中了我的痛点。这种活真是太有技术含量了,高深到让人需要注意太多的东西,需要做非常多的前期功课。
前段时间,发生了一起硬件问题,发现某一台MySQL备库服务器出现了硬件错误,因为是从库服务器的故障,所以就没有很着急得去处理,简单排查发现从库硬件问题无法修复,就申请新机器去尝试重搭从库了。初步分析问题情况如下:

不能轻视的MySQL重启过程


但是让人意外的是准备在线搭建从库的时候,发现主库中没有开启binlog,所以我们看到的从库其实是一个独立的主库,而个真正的主库服务器也已经裸奔了很长时间,其实没有从库,想想这种情况,就让人后背发凉,需要赶紧修复这个问题。这个时候发现问题情况如下:

不能轻视的MySQL重启过程


所以就简单进行了评估,发现还有一台mysql服务器也没有开启binlog,而且也没有从库服务器,于是这个问题的修复就是需要重新搭建两个从库。而binlog的开启需要重启mysql数据库,所以任务就很自然变成了在特定的维护窗口去重启这两台mysql主库服务器,然后在这个基础上搭建从库。
所以这个时候问题情况如下:

不能轻视的MySQL重启过程


对于开启mysql的binlog就跟Oracle开启归档模式差不多,你说这个过程有多复杂,其实就是在重启的过程中重新初始化一番。
我们确定了详细的时间范围,操作步骤,和其他team互相协调配合等等,看起来工作已经做的很充分了。
dba这边也没有掉以轻心,除了开启binlog,也向mysql的同事咨询看还有什么参数可以考虑优化的,所以这个工作看起来重启也着实不算吃亏,还顺便能够调优一下。
计划是下面的情况:

不能轻视的MySQL重启过程


一切都安排就绪,在等待重启的几天时间里,也做了异地的备份,以备不时之需。
对于这次重启,感觉也没有什么需要特别注意的了,也甚至考虑了要不要设置crontab来重启,要不要使用自动化脚本来搭建备库等。因为自己也还算mysql新手,还是摸清了门路再放开手脚。
计划就在今天早晨,和系统那边的约定是在早晨5点左右。大晚上也没睡好,半夜醒来就怕睡过了头,然后反反复复醒来,最后感觉老是醒来看手机,电话太吵影响家人,索性抱着被子到客厅里去睡了,结果睡到了5点半,终于电话来了,开始干活。
首先是使用show processlist检查是否连接已经关闭,还得确认一番,最后准备停mysql库了,发现pid文件怎么没了。
# /etc/init.d/mysql stop
MySQL (Percona Server) PID file could not be found![FAILED]
# ll /home/mysql/mysql.pid
ls: /home/mysql/mysql.pid: No such file or directory
然后还得伪造一个pid文件,在里面手工填入mysqld的进程号。
然后再次尝试就没有问题了,也算小小虚惊一场。
然后停完服务,开始替换参数配置,重启服务,一切都进行的很自然。还准备回头先睡一会,再搭从库。
同事突然反应说error.log里面有很多的警告。
一部分是连接的问题,内容如下:
2015-12-22 07:57:41 26782 [Warning] Aborted connection 1417 to db: 'unconnected' user: 'unauthenticated' host: 'test_app_128.100' (Got an error reading communication pa
ckets)
2015-12-22 07:57:47 26782 [Warning] Aborted connection 1418 to db: 'unconnected' user: 'unauthenticated' host: 'test_app_4.176' (Got an error reading communication pack
ets)
这个部分初步怀疑是不是mysql的参数设置导致的,但是变更的只有log_bin,log_bin_index,cache_size其它的参数都没有动。两台mysql主库的参数修改都是一样的,值得一提的是两台mysql库,一台是5.6,一台是5.5,如果说是版本中的问题导致,那也有些牵强。而且另外一台mysql主库中也有警告,但是警告非常少。
对于这个问题也排查了很多因素,从应用端没有反馈得到错误信息,我们这边也在测试,排除了用户名密码的错误,慢查询的原因,初步怀疑是应用端没有完全关闭连接导致。
另外一部分是mysql数据字典的问题。
2015-12-22 18:19:51 25011 [Warning] InnoDB: Cannot open table mysql/innodb_table_stats from the internal data dictionary of InnoDB though the .frm file for the table exists. See for how you can resolve the problem.
最开始看到这个错误还是让人感觉很奇怪,但是让人无奈的这类错误在1年前就已经存在了,我只是重启了mysql库,其实应该顺带修复这个问题,但是没有引起重视。这类修复还是需要重建这几个数据字典表了,可能需要动ibdata,重启又是需要配合应用来寻找合适的窗口了。
所以通过这个案例,可以看到重启是多么的有技术含量,重启的过程中起到了承上启下的作用,需要充分调研问题,查看是否有遗留问题,一并加以解决,对于其它不明确的问题也需要不断确认,最终逐步深入,应该会把重启中的坑都填平,自己走平坦了,以后大家都方便,这也是规范的起始,让它能够落地。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/42d60245267bcabd84d0189c78f898cc.html