[MDEV-8494] mysqldump ignore-table doesn't ignore mysql.slow_log or mysql.general_log Created: 2015-07-17 Updated: 2018-07-01 Resolved: 2015-08-17 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Scripts & Clients |
| Affects Version/s: | 10.0.20 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Michiel Hazelhof | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Debian Jessie X64 |
||
| Issue Links: |
|
||||||||
| Description |
|
When doing a full DB dump with mysqldump some tables are dumped regardles of their appearance in --ignore-table. /usr/bin/mysqldump --defaults-file=/etc/mysql/mydump.cnf -u<user> -p<password> --add-locks --extended-insert --add-locks --add-drop-database --add-drop-table --single-transaction --routines --triggers --all-databases --all-tablespaces --allow-keywords --complete-insert --create-options --events --dump-date>/root/db.sql cat /etc/mysql/mydump.cnf
Still contains the two tables, other mysql.* tables can be ignored, worse in some cases it also contains the drop statement which causes an import to fail! (when dumping the whole server the export includes "/!40000 DROP DATABASE IF EXISTS `mysql`/;" which breaks if we attempt to import it). |
| Comments |
| Comment by Elena Stepanova [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
GieltjE, hi, could you please clarify the last part of the description:
What are "some cases", which DROP statement you are talking about (is it DROP DATABASE which you quoted later, or something else?), and how exactly does it make the import to fail? Thanks. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michiel Hazelhof [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It is the drop database I quoted later, it always happens when dumping the complete server, when importing it it stops with "ERROR 1580 (HY000) at line 639862: You cannot 'DROP' a log table if logging is enabled". | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Well, the DROP DATABASE statement is there because you request it explicitly by adding --add-drop-database to the command line. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michiel Hazelhof [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The drop statement should not be there as every table from that database is excluded, the problem is that the general_log and slow_log cannot be excluded for some reason (they always appear in the dump). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Regarding the DROP DATABASE statement, I can convert it into a feature request. Regarding dumping the table, I do not see it with your command line. The dump only contains CREATE TABLE IF NOT EXISTS for these two tables, but it does not attempt either to drop them or to dump the contents. Could you please check which version of mysqldump you are using, and if it's recent, create and attach an example of a dump file which you are getting? (You can remove all private data, we are only interested in the command line, file structure and file contents related to tables in question). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michiel Hazelhof [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
mysqldump version: mysqldump Ver 10.15 Distrib 10.0.20-MariaDB, for debian-linux-gnu (x86_64) Expected result: A dumb of all databases without general_log, slow_low and column_stats | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
As said above, I don't see this command either drop general_log and slow_log or dump their contents. It only adds CREATE TABLE IF NOT EXISTS statements which should not do any harm. This specifics of log tables was introduced in MySQL 5.5 and documented e.g. here: http://dev.mysql.com/doc/refman/5.5/en/mysqldump.html
If you observe anything different, please attach the resulting dump file. If the essence of the request is that CREATE TABLE IF NOT EXISTS statements must not be there, again, I can convert it into a feature request, if you can provide an example of them being harmful. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michiel Hazelhof [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The resulting dump file:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2015-07-19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
So, there are indeed only CREATE statements for general_log and slow_log. Why are they a problem? I do see a real problem which your scenario reveals – that mysql schema should not be dropped while log_output=TABLE and either general log or slow log is enabled. I think mysqldump should still drop the schema if it's told to do so, but it should turn off this kind of logging first, and restore the value afterwards. It's a little cumbersome to check, but it's doable. However, so far I do not see a problem with (not) ignoring mysql.slow_log or mysql.general_log. I'm not a big fan of the implicit logic for general/slow log tables introduced in MySQL while fixing http://bugs.mysql.com/bug.php?id=26121 and http://bugs.mysql.com/bug.php?id=45740, but it's already there, and making it even more complicated will only make things worse. Removing these CREATE TABLE IF NOT EXISTS statements would not make the ERROR 1580 you are getting to go away, but it would cause a problem later. Not writing the DROP DATABASE `mysql` statement, as you suggest, would solve the problem in your particular case, but it would actually reduce mysqldump functionality for no good reason, which is not desirable. Currently I see three reasonable ways to use ignore-table options, all of which mysqldump serves well enough. 1) I have db1 schema, in which t1, t2, ... t10 are valuable tables, while tGarbage is just some trash which should never exist after loading the clean dump, no matter whether it existed before loading it or not. Then, I can create the dump with --add-drop-database --ignore-table=db1.tGarbage, and it will do exactly that. 2) I have db2 schema, in which t1, t2, ... t10 are valuable tables, and tLocal is a very valuable table which should not be touched by the dump no matter what.Then, I can create the dump with --add-drop-table --ignore-table=db2.tLocal, and it will do exactly that. 3) I have both db1 and db2, for db1 I want to do (1), and for db2 I want to do (2). Since the settings are essentially different, I can run mysqldump twice, separately for each schema, and get the desired result. If we do as you suggest and forbid dropping the schema if ignore-table is provided, in general case we will achieve nothing, but will lose the scenario (1). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2015-08-17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
So, as described above, there is indeed an issue with mysqldump --add-drop-database when mysql schema is involved and TABLE logging is turned on; but it has already been filed as | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michiel Hazelhof [ 2018-07-01 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Sorry for the slow reply, but with MariaDB 10.2.16 these problems still occur, if a table is noted as being excluded it should be excluded no matter the use case (it just means the tool is broken).
contents of mydump.cnf
In my opinion it would also be very handy to be able to just exclude entire databases, thus removing the need for exceedingly large ignore-table statements (which are error prone if there are new tables added over the years). |