[MDEV-6344] mysqldump issues FLUSH TABLES, which gets written into binlog and replicated Created: 2014-06-16  Updated: 2014-07-09  Resolved: 2014-07-09

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.38, 10.0.11
Fix Version/s: 10.0.13

Type: Bug Priority: Critical
Reporter: Kristian Nielsen Assignee: Kristian Nielsen
Resolution: Fixed Votes: 0
Labels: gtid, replication


 Description   

mysqldump has this code:

    ( mysql_query_with_error_report(mysql_con, 0, 
                                    ((opt_master_data != 0) ? 
                                        "FLUSH /*!40101 LOCAL */ TABLES" : 
                                        "FLUSH TABLES")) ||

The conditional use of LOCAL seems to come from this mysql bug:

http://bugs.mysql.com/bug.php?id=35157

But I think the patch for that bug is rather confused. I do not think there is
ever a reason for mysqldump to issue a FLUSH TABLES that will be written into
the binlog and replicated to slaves. It should always use LOCAL.

This is particularly serious in 10.0+ where we have GTID. In this case, any
attempt to mysqldump a slave will silently inject a local binlogged
transaction on the slave, which causes that slave to have an alternate future
(extra GTID not present on the master), which is generally a bad thing.

So I propose to fix this in 10.0 by using LOCAL unconditionally.



 Comments   
Comment by Kristian Nielsen [ 2014-06-17 ]

Patch: http://lists.askmonty.org/pipermail/commits/2014-June/006208.html

Comment by Kristian Nielsen [ 2014-06-25 ]

This has passed review.
However, it will not be pushed until MDEV-6336 has been reviewed, as it is contained in the same patch.

Comment by Kristian Nielsen [ 2014-07-09 ]

Pushed to 10.0.13

Generated at Thu Feb 08 07:11:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.