如前文所述,最近在做mysql的备份mysqldump之跳过指定表
问题描述
在使用crontab的时候再次碰到了错过很多次的神坑。特此记录一下
- 手动执行脚本没有问题,crontab执行无结果
- 手动执行脚本无异常,crontab执行结果异常(不一致)
脚本如下
#!/bin/bash
/usr/local/mysql/bin/mysqldump -uroot -pXXX --skip-lock-tables --databases f6dms_trial $(mysql -uroot -pXXX -Df6dms_trial -Bse "show tables like 'tm_monitor_avg_price_%'"|awk '{print "--ignore-table=f6dms_trial."$1}'|xargs)| gzip > /data/backup/f6dms-trial_`date '+%Y-%m-%d-%H:%M:%S'`.sql.gz;
/usr/local/mysql/bin/mysqldump -uroot -pXXX --skip-lock-tables --databases f6db_trial f6report_new_trial | gzip > /data/backup/f6db-trial_`date '+%Y-%m-%d-%H:%M:%S'`.sql.gz;
30 1 * * * /data/shell/backupdb.sh;
注意到写到mysqldump是用了绝对路径
- 第一次写的时候没有用绝对路径,执行后直接没有dump,遂改造成用绝对路径(没有读取默认环境变量,导致无法识别mysqldump指令)
- 第二次改造时忘记了这件事情直接使用了mysql
默认情况下直接手动执行没有问题(读取到了当前环境变量)
当使用crontab时,并不会默认读取当前环境变量,导致备份数据库依然全备份 (mysql指令不能识别导致无法拼接出 --ignore-table)
解决方案
- 使用绝对路径,不关心path
#!/bin/bash
/usr/local/mysql/bin/mysqldump -uroot -pXXX --skip-lock-tables --databases f6dms_trial $(/usr/local/mysql/bin/mysql -uroot -pXXX -Df6dms_trial -Bse "show tables like 'tm_monitor_avg_price_%'"|awk '{print "--ignore-table=f6dms_trial."$1}'|xargs)| gzip > /data/backup/f6dms-trial_`date '+%Y-%m-%d-%H:%M:%S'`.sql.gz;
/usr/local/mysql/bin/mysqldump -uroot -pXXX --skip-lock-tables --databases f6db_trial f6report_new_trial | gzip > /data/backup/f6db-trial_`date '+%Y-%m-%d-%H:%M:%S'`.sql.gz;
- 默认读取当前环境变量,因此在脚本中加入如下
#!/bin/bash
###################
. /etc/profile
. ~/.bash_profile
##################
mysqldump -uroot -pXXX --skip-lock-tables --databases f6dms_trial $(mysql -uroot -pXXX -Df6dms_trial -Bse "show tables like 'tm_monitor_avg_price_%'"|awk '{print "--ignore-table=f6dms_trial."$1}'|xargs)| gzip > /data/backup/f6dms-trial_`date '+%Y-%m-%d-%H:%M:%S'`.sql.gz;
mysqldump -uroot -pXXX --skip-lock-tables --databases f6db_trial f6report_new_trial | gzip > /data/backup/f6db-trial_`date '+%Y-%m-%d-%H:%M:%S'`.sql.gz;
此问题已经踩过多次坑,当牢记!!!
网友评论