关于几个MySQL环境问题的对比

  1. 云栖社区>
  2. 博客>
  3. 正文

关于几个MySQL环境问题的对比

jeanron100 2016-01-02 23:34:10 浏览405
展开阅读全文
有时候出现了环境问题,对比是一种很好的方式,如果对比得当,可以避免反复的出现问题,可以根据对比的情况推理出一些可能出现的情况或者问题。
如果对比不当,很可能得出错误的结论。今天就简单举几个例子来说明一下。
MySQL重启的对比
之前出现过一次备机的硬件故障,但是庆幸的是幸亏是备机,备机上意味值有备库,但是实际发现备机上的备库和主库没什么关联,也是让人直冒冷汗,那就搭建备库吧,结果发现主库没有开启binlog,这种情况下是没有任何办法的,所以在评估之后,发现还有一套环境也是同样的问题,所以就申请了窗口时间来做重启的工作,期间也对本身数据库层面的参数考虑了优化,所以重启涉及两套环境,一套是5.5,一套是5.6,为了保险起见,5.6的mysql也保持了5.5的原有配置,没有开gtid.重启的过程实在没有技术含量,但是重启之后从数据库日志中出现了一些告警,告警信息如下:
2015-12-22 07:42:23 26782 [Warning] Aborted connection 1238 to db: 'unconnected' user: 'unauthenticated' host: 'gate_app_4.172' (Got an error reading communication pack
ets)
2015-12-22 07:42:30 26782 [Warning] Aborted connection 1242 to db: 'unconnected' user: 'unauthenticated' host: 'gate_app_131.41' (Got an error reading communication pac
kets)
这个让我们颇有些意外,对于这种情况,从对比的角度来看,有以下几种场景。
对比场景1:是不是5.5,5.6的参数设置影响,是否是5.6中的bug,因为有问题的是5.6的mysql服务器。
很显然不是,因为5.6的配置我没有修改其它的参数,只是开启了binlog,原有的配置为了保险起见都没有做变更。两套环境的变更情况都是一样。
对比场景2:是不是5.6的环境重启的时候出了问题。
这个也可以排除,因为两台服务器都是做重启,另外一台服务器就没有类似的问题。
对比场景3:对于这个问题,是否需要从应用端来查看是否有长连接未释放的情况
这个也进行了排查,在应用端来看,没有发现相关的问题,而且涉及环境着实很多。
对比场景4:最近存在一些网络的变更,是否和dns的变更有一定的影响
对这个也求助了系统组进行协助,但是没找到什么相关的日志。
对比场景5:重启前和重启后进行对比。
重启前和重启之后的日志信息是否有大的出入,当时查看error.log的时候看到报出了好几页的告警信息,也就没有再往前翻更多的,看了4,5页都是告警信息,哪想到查看之前的日志,发现以前也有类似的问题。
所以这种对比,有一个基准,和其它的环境做对比,可能也会得出一些相关的结论,但是当前环境的重启前后做对比更能体现出问题的根源,如果之前就存在此类的问题,那就说明这是个历史遗留问题,这些应用已经可以停止尝试连接了。

MySQL导入dump
前端时间做几套基于云服务器下的MySQL数据迁移,碰到了几个问题,当时还比较困扰我。
因为数据量不大,所以就采用了mysqldump做了逻辑导出,然后直接在目标环境逻辑导入。因为是新环境,所以有些库导入没有任何问题,有一个库总是在导入的时候会自动退出。
报错内容为:
 ERROR 2013 (HY000) at line 8441: Lost connection to MySQL server during query
当然对于这个问题,用了一下几个对比场景来尝试。
首先环境的内存是16g,存在3个dump,分别为10g,20g,30g,最开始为了省事,我就开启了三个nohup的进程去并发导入,数据在不同的数据库中。
场景1:  并发导入3个dump,导入失败
场景2:  串行导入也报错,接着使用串行的方式导入,依旧失败,因为自己也是稍后查看的日志,发现导入失败,不确定全部都顺利完成。
场景3:  当然还在联调阶段,所以我还有一些时间来多做一些测试,然后导入20G,发现依旧失败。
场景4:按照对比的思路,30g肯定也是导入不了,确实导入不了,不过发现30g的dump中在某一个表分区时导入就会失败
场景5:尝试对30g的dump中的这个分区表单独导入,发现依旧存在问题。不过所幸开始查看日志,发现原来是 oom-killer导致, 这个和剩余内存少密切相关,当然也和swap相关。
场景6:发现这些云服务器都没有配置swap,添加了swap之后,  导入10g的dump,就成功了。
场景7: 导入20g,也成功了,但是swap使用率在10g左右,swap配置了16G,为什么在10g左右徘徊呢,这个和swap的默认配置使用率有关,默认是60%,也就是9.6G左右,和现象中的10g是一致的。那么为什么会消耗大量的swap呢,初步怀疑是因为在线导入,因为业务上开始做联调了,不能够停应用,所以就出现了在线导入数据的情况。
场景8:那么接着导入30g的dump,是否依旧成功呢,遗憾的是这次还是失败了, 因为发生了oom-killer,对应的线程被终止了,swap彻底释放,swap使用量一下子重置为5M了。
场景9: 这个时候再次尝试导入30g的dump,就没有问题了,不过因为在线导入,会有一些锁等待,而且对于资源的消耗着实够高,swap使用率到了10G左右
场景10: dump已经导入成功,为什么swap没有释放呢,一种方式就是重新挂载swap分区,但是让人郁闷的是还是因为内存不足。报出了下面的错误。
#swapoff -a
swapoff: /home/swapfile: swapoff failed: Cannot allocate memory
那么这种情况改怎么办,目前来看重启是一个唯一奏效的方案了。联系应用重启,但是一直没协调下来,所以就这样耽误了几天。
场景11:过了几天之后我再次查看,发现swap已经自动重置了,而重置的原因还是oom-killer,看来应该是有个连接被强制终止之后,触发了oom-killer,然后swap彻底释放。
那么这么多看起来琐碎的场景,有个问题就是为什么内存总是不足呢,除了swap还应该有些原因吧,最后发现还有一个原因就在于buffer_pool_size设置过大,本来16g的内存,结果buffer_pool_size竟然设置了24G,为什么会出现这种低级错误呢,追根溯源发现原来使用的模板只校验redhat,没有校验centos,而这台服务器上安装的恰恰是centos,所以在初始化参数的时候给直接设置了成了24G,所以这个模板也存在一些问题,本身的校验逻辑还是不够严谨。

对比了一圈,发现对比有时候可以帮助我们分析问题,有的时候也会误导我们,凡事有度,当然如果做一件事情,没有任何的输出和结论,也是没有实际意义的。

网友评论

登录后评论
0/500
评论
jeanron100
+ 关注