今天上班的路上收到一条短信，显示线上所有实例备份都失败了。备份失败是大事，于是到公司的第一件事儿就是排查备份失败的原因。

　　这两天迁移了数据库管理平台，当然涉及到数据库备份功能，备份失败肯定和平台迁移有一定关系，我们先聊聊线上备份方案：

　　目前线上的备份方案是：

　　　　1、有一个前端页面可以配置备份任务

　　　　2、备份任务配置好了，会自动刷新到系统的crontab定时通过ansible远程执行。

     排查过程：

          1、查看备份报告，显示所有的备份文件大小都是0，初步估计是备份失败了而不是元数据没有更新的问题。

          2、去机器上面查看备份日志：

             从日志上面查看是备份已经成功，但是去过去备份文件大小的时候抛文件不存在的异常。

             不知道大家有没遇到这种情况，不过问看到这种现象首先想到的是有多个任务在跑，上一个备份还没完成就被另外一个备份任务将备份文件删除了。方面就初步出来了，就是要找到另外一个任务是怎么来的。

           3、我先挑选了一个比较小的非核心集群，尝试了手动执行了crontab里面的备份命令，备份成功(这只是确认一下，因为平台迁移后测试过备份任务是没有问题的)

           4、由于每一个集群的备份全部失败了，也就是说，两个备份任务能连接到线上所有的mysql机器，有这权限的只有3台服务器，于是去查了这三台服务器是否有重复的定时任务。结果只有一台机器上面才定时任务。

           5、上面的尝试也没找到原因，就只能继续尝试，将备份任务的时间修改为当前时间+2分钟，让它定时执行看是否正常。

                  结果和晚上备份情况一样还是失败。

           6、到这个时候我已经有点懵了，感觉这个太不科学了，期间还让开发平台的同事帮忙查看了代码里面生成crontab部分是否有问题，比如在其他机器上同时有生成，结果都是大失所望。

           7、继续其他尝试，对比手动执行和定时任务产生的进程：

                 在目标机器使用ps -ef |grep backup.sh 

                        a) 手动执行的时候：为2个进程

                        b) crontab定时执行的时候：为4个进程，

                        这个还是只能肯定定时任务有问题，并不能说明什么原因造成这个现象的。

                        只能继续蒙圈…………

            8、在不知道怎么排查问题的时候，我做了一个新的尝试。

                 在配置好定时任务的时候，在中控机上使用service crond stop 将定时服务给停了，如果备份成功了那说明需要在其他机器找问题

           9、这次尝试确实后备份确实成功了，但是在其他机器也找不到原因，这时候 已经很抓狂了，完全不知道什么情况了。

           在准备放弃的时候，我在中控机上面使用 ps -ef |grep crond  查看crond 服务的情况。尼玛，内心10000个草泥马飞奔，居然还有有一个crond服务！！

                      使用service crond start 启动crond，

                       居然有两个服务。

                  看到这里终于可以松口气，看来问题就在这里了，

                 于是将多余的crond 服务 kill掉后备份就正常。

       ps：crond 这个服务个人确实从来没发现可以启动两个的，后面我做了各种尝试，最终还是只有一个服务，至今也不知道这个第二个crond服务怎么起来的。

             遇到自己感觉灵异的问题，我们要相信机器不会撒谎，我们要保持清晰的思路，坚持下去，终究能找到问题所在的。

             话是这么说，但是事实上做起来还是很难的，我差点就放弃，准备将这套备份系统直接下了，用自己新写的一套来替代，本地已经测试ok，只要上线跑跑就可以了。不过还是挺庆幸当时没有放弃，如果放弃了，那么我也就错过了crond服务还有可能出现两个的奇观了！

嘿嘿，提个问题，如果你们遇到这种情况，会用什么思路来排查呢？

记crond导致备份失败的排查过程