Bug #2222 mysqldump -A -F creates new binlogs for each db dumped
Submitted: 27 Dec 2003 9:54 Modified: 3 Feb 2004 10:52
Reporter: Stefan Hinz Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: mysqldump Command-line Client Severity:S3 (Non-critical)
Version:4.0.16 OS:Microsoft Windows (Windows 2000)
Assigned to: Guilhem Bichot CPU Architecture:Any

[27 Dec 2003 9:54] Stefan Hinz
Two comments on http://www.mysql.com/doc/en/mysqldump.html#comments
refered to "the -A -F problem". The commenters were complaining about
the fact that for each database dumped, the logs are flushed, and thus
a new binlog is written.

I'd regard that as a feature, and added a note to the -F option
description. I also removed those comments :-)

I asked Paul about this; here's his opinion:

I'd regard it as a feature, too, because it helps make restore
operations that require the binlogs more reliable.  The different
binlogs serve essentially as checkpoints.  At least, that's how I'd
understand it.

Serg, however, stated this:

I personally would take it as a bug.
At least mysqldump --help says:
  -F, --flush-logs    Flush logs file in server before starting dump.

And I see no reason for the curremt behaviour.

How to repeat:
Issue mysqldump -A -F and look at the binlogs.

Suggested fix:
Make mysqldump -A -F _not_ flush logs for each db dumped.
[30 Jan 2004 8:36] Michael Widenius
I updated mysqldump --help to reflect the actual usage.
[3 Feb 2004 10:52] Sergei Golubchik
The reason for flushing logs between databases is that mysqldump locks one database at time, so it has to flush logs per database to get a consistent snapshot.

And it locks one database in time because
1. we don't want to make ALL tables read-only for the duration of the WHOLE backup
2. we don't want to open ALL tables at once (and LOCK TABLE opens it) because mysqld can simply get short of file descriptors and it's slow.