专栏首页杨建荣的学习笔记不能轻视的mysql重启过程 (r7笔记第55天)

不能轻视的mysql重启过程 (r7笔记第55天)

数据库的重启看似是一件非常简单,没有技术含量的活,这是我以前说的话。而这句话简直是戳中了我的痛点。这种活真是太有技术含量了,高深到让人需要注意太多的东西,需要做非常多的前期功课。

前段时间,发生了一起硬件问题,发现某一台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,重启又是需要配合应用来寻找合适的窗口了。

所以通过这个案例,可以看到重启是多么的有技术含量,重启的过程中起到了承上启下的作用,需要充分调研问题,查看是否有遗留问题,一并加以解决,对于其它 不明确的问题也需要不断确认,最终逐步深入,应该会把重启中的坑都填平,自己走平坦了,以后大家都方便,这也是规范的起始,让它能够落地。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes),作者:杨建荣

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2015-12-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • MySQL 5.6, 5.7并行复制测试(r12笔记第9天)

    对于主从延迟,其实一直以来就是一个颇有争议的话题,在MySQL阵营中,如果容忍一定的延迟的场景,通过主从来达到读写分离是个很不错的方案,但是延迟率到底有多...

    jeanron100
  • MySQL关于数据字典的一个疑问

    今天看着MySQL的数据字典,突然想到一个问题:为什么MySQL数据字典 information_schema中的表名是大写,而performance_sche...

    jeanron100
  • 最近的几个技术问题总结和答疑 (r8笔记第19天)

    笔记写了不少,有时候有的朋友问我几个关键字,我就会从脑海里进行搜索,凡是写过的,搜索一下总能找到,帮助了别人,提高了自己,何乐而不为。 但是笔记写了很多...

    jeanron100
  • Mysql指令select,update,insert,drop,truncate+MySQL数据库备份恢复

    一、select: 1.1 选择db1中mysql库和user表: mysql> use db1 Database changed mysql> select ...

    老七Linux
  • mac 解决 mysql 启动报错

    mac 中用 brew 安装 mysql,理想中是这样的:执行一行命令,就可以愉快地使用 mysql

    章鱼喵
  • docker安装mysql及navicat远程连接

    华创信息技术
  • [docker]安装Mysql

    贰叁壹小窝
  • macOS 安装 mysql

    打开下载页面 https://dev.mysql.com/downloads/mysql/5.7.html ,下载镜像安装文件。

    我是一条小青蛇
  • Mysql总结_03_mysql常用命令

    一、MySQL服务的启动和停止  net stop mysql  net start mysql 二、登陆mysql mysql -u用户名 -p用户密码

    shirayner
  • 地表最强的MySQL安装一键式安装,信不信你下完我就给你装好!附各种Mysql安装失败的解决办法(什么你安装失败了?快来看这个)

    第一步下载我的压缩包 链接:https://pan.baidu.com/s/1EE40dU0j2U1d-bAfj7TeVA 提取码:n25c 复制这段内容...

    风骨散人Chiam

扫码关注云+社区

领取腾讯云代金券