| Bug #4953 | mysqldump --master-data may report incorrect binlog position if using InnoDB | ||
|---|---|---|---|
| Submitted: | 9 Aug 2004 14:54 | Modified: | 20 Aug 2004 17:22 |
| Reporter: | Guilhem Bichot | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: mysqldump Command-line Client | Severity: | S2 (Serious) |
| Version: | 4.0 | OS: | Any (all) |
| Assigned to: | Guilhem Bichot | CPU Architecture: | Any |
[20 Aug 2004 17:22]
Guilhem Bichot
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.
If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html
Additional info:
ChangeSet@1.1968.1.2, 2004-08-20 16:35:23+02:00, guilhem@mysql.com
Description: This is just a consequence of the "FLUSH TABLES WITH READ LOCK does not block COMMIT" bug, but I'll enter it here as I can fix mysqldump to work around the bug (but can't fix the bug itself yet). Scenario: * user1 USE test; CREATE TABLE i (a INT) TYPE=INNODB; BEGIN; INSERT INTO i VALUES(1); * user 2: patch mysqldump so that it sleeps before SHOW MASTER STATUS, then mysqldump --master-data test i prints the table as empty, then sleeps; during the sleep: * user 1 COMMIT; * user 2 when sleep finishes, it does SHOW MASTER STATUS and so reports the binlog position of the end of the COMMIT. Which is not correct, as the printed data ("empty") is not of this position. Thus breaking later recovery from this backup (if you use the output of mysqldump as a backup). How to repeat: see description. Suggested fix: Will implement a workaround into mysqldump.