Bug #73733 mysqldump manual page wrong about --all-databases and --single-transaction

Submitted: 27 Aug 2014 0:42 Modified: 1 Oct 2014 15:02
Reporter: Justin Swanhart Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Documentation Severity:S3 (Non-critical)
Version:all OS:Any
Assigned to: David Moss CPU Architecture:Any

[27 Aug 2014 0:42] Justin Swanhart 
Description:
shell> mysqldump --all-databases --single-transaction > all_databases.sql
This backup acquires a global read lock on all tables (using FLUSH TABLES WITH READ LOCK) at the beginning of the dump. As soon as this lock has been acquired, the binary log coordinates are read and the lock is released. If long updating statements are running when the FLUSH statement is issued, the MySQL server may get stalled until those statements finish. After that, the dump becomes lock free and does not disturb reads and writes on the tables. If the update statements that the MySQL server receives are short (in terms of execution time), the initial lock period should not be noticeable, even with many updates.

How to repeat:
This is describing instead:
shell> mysqldump --all-databases --single-transaction --master-data=1 > all_databases.sql

Suggested fix:
Fix the manual and add --master-data=1
[27 Aug 2014 8:27] MySQL Verification Team 
Hello Justin,

Thank you for the report.

Thanks,
Umesh
[1 Oct 2014 15:02] David Moss 
Fixed in all versions of the manual from 5.0 upwards with commit 40311.
[1 Oct 2014 15:06] David Moss 
Posted by developer:
 
Fixed in all versions of the manual from 5.0 upwards with commit 40311.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.049 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.