mysqldump add-drop-database导致恢复失败原因和处理

1、问题

通常用mysqldump+source做数据备份和恢复。如果想要完全恢复备份时的状态，要删掉新表，一般思路就是让mysqldump生成drop database + create database.

bin/mysqldump -Srun/mysql.sock -uroot --all-databases --add-drop-database &>data.sql

但在将生成的data.sql执行source作恢复操作时，会发现报错。

"ERROR 1580 .... You cannot 'DROP' a log table if logging is enabled"

2、原因

在正常执行的服务中，我们会打开慢查询日志。在log_slow_queries 为 on时，mysql.slow_log这个表不允许删除，因此，当source命令执行到drop database if exists mysql 时，就报上面的这个错。

同样的问题会出现在mysql.general_log这个表。只是平时服务中一般不会query_log。

3、影响

由于source是按行执行的，执行到这个语句报错并不影响已经完成的恢复动作。就是说如果有个库叫’ab’，则执行出错前已经恢复，出错后并不回滚。可能导致数据不一致。

而且dump+source作为标准操作，上述的这个现象看上去比较bug.

4、处理

一种处理方法是在dump出来的文件中，将drop database if exists mysql这句话删除掉。

这麻烦一些，还需要人工或这脚本。也可以简单修改mysqldump.c。策略上对于mysql这个库，不要生成drop database语句。简单如下：

4105c4105
<       if (opt_drop_database)
---
>       if (opt_drop_database && my_strcasecmp(qdatabase, quote_name("mysql", qbuf,
opt_quoted))!=0)
4115c4115
<       if (opt_drop_database)
---
>       if (opt_drop_database && my_strcasecmp(qdatabase, quote_name("mysql", qbuf,
opt_quoted))!=0)

5、注意

有的同学会提出在source的时候先把slow_log关掉，这样执行drop mysql这个库的时候就能通过。

需要注意一点是这样source完成后slow_log和general_log这两个表就没了，当你再执行 set global slow_query_log=1; 时，就会提示slow_log不存在而无法完成。

因此使用这种方法需要备份这两个表，source完成后再拷回mysql目录。