转载

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

有时候出现了环境问题，对比是一种很好的方式，如果对比得当，可以避免反复的出现问题，可以根据对比的情况推理出一些可能出现的情况或者问题。
如果对比不当，很可能得出错误的结论。今天就简单举几个例子来说明一下。
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,所以这个模板也存在一些问题，本身的校验逻辑还是不够严谨。

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

正文到此结束