记crond导致备份失败的排查过程
今天上班的路上收到一条短信,显示线上所有实例备份都失败了。备份失败是大事,于是到公司的第一件事儿就是排查备份失败的原因。
这两天迁移了数据库管理平台,当然涉及到数据库备份功能,备份失败肯定和平台迁移有一定关系,我们先聊聊线上备份方案:
目前线上的备份方案是:
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服务还有可能出现两个的奇观了!
嘿嘿,提个问题,如果你们遇到这种情况,会用什么思路来排查呢?