数据库的重启看似是一件非常简单，没有技术含量的活，这是我以前说的话。而这句话简直是戳中了我的痛点。这种活真是太有技术含量了，高深到让人需要注意太多的东西，需要做非常多的前期功课。
前段时间，发生了一起硬件问题，发现某一台mysql备库服务器出现了硬件错误，因为是从库服务器的故障，所以就没有很着急得去处理，简单排查发现从库硬件问题无法修复，就申请新机器去尝试重搭从库了。初步分析问题情况如下：
但是让人意外的是准备在线搭建从库的时候，发现主库中没有开启binlog,所以我们看到的从库其实是一个独立的主库，而个真正的主库服务器也已经裸奔了很长时间，其实没有从库，想想这种情况，就让人后背发凉，需要赶紧修复这个问题。这个时候发现问题情况如下：
所以就简单进行了评估，发现还有一台mysql服务器也没有开启binlog,而且也没有从库服务器，于是这个问题的修复就是需要重新搭建两个从库。而binlog的开启需要重启mysql数据库，所以任务就很自然变成了在特定的维护窗口去重启这两台mysql主库服务器，然后在这个基础上搭建从库。
所以这个时候问题情况如下：
对于开启mysql的binlog就跟oracle开启归档模式差不多，你说这个过程有多复杂，其实就是在重启的过程中重新初始化一番。
我们确定了详细的时间范围，操作步骤，和其他team互相协调配合等等，看起来工作已经做的很充分了。
dba这边也没有掉以轻心，除了开启binlog，也向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 http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
最开始看到这个错误还是让人感觉很奇怪，但是让人无奈的这类错误在1年前就已经存在了，我只是重启了mysql库，其实应该顺带修复这个问题，但是没有引起重视。这类修复还是需要重建这几个数据字典表了，可能需要动ibdata,重启又是需要配合应用来寻找合适的窗口了。
所以通过这个案例，可以看到重启是多么的有技术含量，重启的过程中起到了承上启下的作用，需要充分调研问题，查看是否有遗留问题，一并加以解决，对于其它不明确的问题也需要不断确认，最终逐步深入，应该会把重启中的坑都填平，自己走平坦了，以后大家都方便，这也是规范的起始，让它能够落地。
前段时间，发生了一起硬件问题，发现某一台mysql备库服务器出现了硬件错误，因为是从库服务器的故障，所以就没有很着急得去处理，简单排查发现从库硬件问题无法修复，就申请新机器去尝试重搭从库了。初步分析问题情况如下：
但是让人意外的是准备在线搭建从库的时候，发现主库中没有开启binlog,所以我们看到的从库其实是一个独立的主库，而个真正的主库服务器也已经裸奔了很长时间，其实没有从库，想想这种情况，就让人后背发凉，需要赶紧修复这个问题。这个时候发现问题情况如下：
所以就简单进行了评估，发现还有一台mysql服务器也没有开启binlog,而且也没有从库服务器，于是这个问题的修复就是需要重新搭建两个从库。而binlog的开启需要重启mysql数据库，所以任务就很自然变成了在特定的维护窗口去重启这两台mysql主库服务器，然后在这个基础上搭建从库。
所以这个时候问题情况如下：
对于开启mysql的binlog就跟oracle开启归档模式差不多，你说这个过程有多复杂，其实就是在重启的过程中重新初始化一番。
我们确定了详细的时间范围，操作步骤，和其他team互相协调配合等等，看起来工作已经做的很充分了。
dba这边也没有掉以轻心，除了开启binlog，也向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 http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
最开始看到这个错误还是让人感觉很奇怪，但是让人无奈的这类错误在1年前就已经存在了，我只是重启了mysql库，其实应该顺带修复这个问题，但是没有引起重视。这类修复还是需要重建这几个数据字典表了，可能需要动ibdata,重启又是需要配合应用来寻找合适的窗口了。
所以通过这个案例，可以看到重启是多么的有技术含量，重启的过程中起到了承上启下的作用，需要充分调研问题，查看是否有遗留问题，一并加以解决，对于其它不明确的问题也需要不断确认，最终逐步深入，应该会把重启中的坑都填平，自己走平坦了，以后大家都方便，这也是规范的起始，让它能够落地。
