有时候出现了环境问题，对比是一种很好的方式，如果对比得当，可以避免反复的出现问题，可以根据对比的情况推理出一些可能出现的情况或者问题。
如果对比不当，很可能得出错误的结论。今天就简单举几个例子来说明一下。
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呢，初步怀疑是因为在线导入，因为业务上开始做联调了，不能够停应用，所以就出现了在线导入数据的情况。