如前文所述，最近在做MysqL的备份mysqldump之跳过指定表

问题描述

在使用crontab的时候再次碰到了错过很多次的神坑。特此记录一下

1. 手动执行脚本没有问题，crontab执行无结果
2. 手动执行脚本无异常，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是用了绝对路径

1. 第一次写的时候没有用绝对路径，执行后直接没有dump，遂改造成用绝对路径（没有读取默认环境变量，导致无法识别MysqLdump指令）
2. 第二次改造时忘记了这件事情直接使用了MysqL

默认情况下直接手动执行没有问题（读取到了当前环境变量）

当使用crontab时，并不会默认读取当前环境变量，导致备份数据库依然全备份 （MysqL指令不能识别导致无法拼接出 --ignore-table）

解决方案

1. 使用绝对路径，不关心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;

2. 默认读取当前环境变量，因此在脚本中加入如下

   #!/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;

   此问题已经踩过多次坑，当牢记！！！