Linux系统crontab备份数据库执行不成功？可能是百分号%在作怪！

之前博客分享过一篇《Linux/vps本地七天循环备份和七牛远程备份脚本》，我自己也一直在用。某天检查备份的时候，突然发现数据库的备份的压缩包是空的！

看了下crontab的日志，发现有如下错误：

Access denied for user 'dbuser'@'localhost' to database 'db' when using LOCK TABLES

原来，我在计划任务中备份数据库时，用的是普通用户，在凌晨三点备份的时候，可能碰巧网站正在被访问（比如蜘蛛抓取）。由于存在数据查询，所以mysqldump将默认执行锁表机制。

由于普通用户没有锁表权限，从而导致此次备份失败！

我立马更新了该文章，补充了出现这种情况的解决办法：

解决办法：

方法①、修改上面的备份脚本，找到如下行

mysqldump -u$mysqluser -p$mysqlpd $dbname>$back_path/$domain\_db_$TODAY\.sql

添加--skip-lock-tables参数即可，即不锁表导出（可能丢失某些正在更新的数据，当然凌晨时候几率很小）。

mysqldump -u$mysqluser -p$mysqlpd $dbname --skip-lock-tables>$back_path/$domain\_db_$TODAY\.sql

方法②、使用root帐号执行备份即可：

执行crontab -e 修改Linux计划任务，修改数据库备份计划命令行中的用户名为mysql的root帐号：

5 3 * * * /root/backup.sh db zhang.ge zhangge_db root rootpasswd /home/wwwbackup/zhang.ge

个人推荐方法②，最大限度的保证了数据备份的完整度！

我自己用的就是第②种方法，使用mysql的root帐号来备份，我自以为是的以为应该是万无一失的！

今天再次检查备份的时候发现，数据库仍然没有备份！空的压缩包都不存在了！

可是手动执行crontab里面的数据库备份语句又是可以的，真是诡异！！

于是开始debug，设置断点、使用绝对路径，各种方法用尽了，居然还是不行，不过发现当我将数据库备份代码写到另外一个脚本，然后将这个脚本加入到crontab的时候却可以了？？？这是为毛？

脚本所用的备份代码是：

于是，我修改backup.sh脚本，将里面的$1~$6都输出到日志中，结果让我发现了问题所在！！！

原来问题出在脚本参数上：我的mysql的root密码中含有一个百分号%，直接将上面的代码写到crontab中，这个百分号却无法传递，所以脚本取得的密码就是错误的！从而，备份失败！

经过查询，发现百分号%是crontab中的一个特殊符号！不能直接作为参数传递！！！

解决办法很简单，使用反斜杠\转义即可：\%，假如我的密码是 123456%，那之前脚本的crontab备份代码应该是：

还是经验不足啊！我也确实没在crontab中使用过百分号字眼，这次算是涨姿势了！