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目录。

上一篇:Azure 中国篇之网络服务—(2)Azure虚拟机使用公网ip(PIP)


下一篇:sql server 备份与恢复系列四 大容量模式下的备份与还原