crontab的mysqldump备份任务未能完全正确执行的故障处理

  crontab是每个运维一线人员必须掌握的技术，熟练运用crontab可以自动帮助我们执行重复性的工作，提高运维的工作效率。它就像一个闹钟，在特定的时间，准时响应并执行相应的任务。如果你的工作经常与Linux打交道，那么你可以继续往下看，了解crontab的一般性故障排查。

  本次的故障发生在生产环境的一台云服务器上，每日凌晨2点15执行数据库的mysqldump备份任务，保留最近的三天备份，删除之前多余的备份文件。当第四天执行完计划任务的时候发现本地备份目录中居然还存留三天前的压缩备份文件，调试脚本检查并无问题后，手动执行crontab的脚本，发现crontab能完全正确执行，而第二天再次通过crontab的方式执行发现仍然多保留了一天的压缩备份文件。（这里可以通过touch命令新建空文件或者修改文件时间来模拟）

  通过与其他同行沟通并谷歌或百度搜索，发现了两种解决这种问题的方案，如下是我的本次故障的排查流程。因故障发生于阿里云的生产服务器，故障排查的现象过程不便于重现，敬请谅解，对于生产服务器我们还是应当谨慎的操作，不便于做测试任务。

【故障情景】

  一台阿里云的云服务器，crontab手动和自动均能执行备份任务，自动执行后备份的文件相对只保留三天却多保留一天，而手动执行却能保存三天的备份，而本地的物理机就能成功执行，只有云服务器多保留一天的备份。

#删除未压缩的备份目录
function rm_oldfile()
{
  cd $backupdir
  find ./ -type f -mtime +2 -exec rm {} \;
}

#需要清理备份的时候把下面注释去掉，天数可以自行修改
rm_oldfile;

【故障分析】

  crontab出现故障，会有两个原因，一个是命令路径的问题，另一个就是环境变量的问题。

【故障排查】

  命令路径都是正确，且相关命令是绝对路径，crontab自动执行不会出现问题。

  第一种解决办法：通过手动加载环境变量，发现问题得到解决，添加如下的登陆shell变量加载。

#!/bin/bash
. /etc/profile
. ~/.bash_profile

  第二种解决办法：加if判断，检查备份文件的数量，如果大于正常值，则再执行find ./ -type f -mtime +2 -exec rm {} \;命令。

function rm_agofile()
{
cd $backupdir
if (($(ls -lh /opt/dump_ibg_mall/|grep ".*.tar.gz"|wc -l) > 3))
then
        find ./ -type f -mtime +2 -exec rm -rf {} \;
else
        echo "there is no more than 3" >>/tmp/dump_ibg_mall_result.log
fi
}
#rm_agofile;

【故障总结】

  crontab的脚本里命令必须绝对路径，或者环境变量可能不会被加载。除了上述两种方式，我们也可以配合if判断，通过其他的逻辑方式来达到我们的需求。