Bug #69059 GTIDs lack a reasonable deployment strategy
Submitted: 24 Apr 2013 20:55 Modified: 11 Feb 2015 14:37
Reporter: Justin Tolmer Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Replication Severity:S2 (Serious)
Version:5.6.11 OS:Any
Assigned to: CPU Architecture:Any

[24 Apr 2013 20:55] Justin Tolmer
Setting up replication using GTIDs, as documented at http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html, includes:

1) If replication is already running, synchronize both servers by making them read-only.

2) Stop both servers.

3) Restart both servers with GTIDs, binary logging, and slave update logging enabled, and with statements that are unsafe for GTID-based replication disabled. In addition, the servers should be started in read-only mode, and the slave SQL and I/O threads should be prevented from starting on the slave.

The mysqld options necessary to start the servers as described are discussed in the example that follows later in this section.

These steps are not reasonable; it is not possible to turn down and restart our entire database topology simultaneously in order to enable GTIDs, making the feature unusable.

How to repeat:
Read the documentation.

Suggested fix:
Implement gtid_mode=UPGRADE_STEP_1 and gtid_mode=UPGRADE_STEP_2, which are partially documented at http://dev.mysql.com/doc/refman/5.6/en/replication-options-gtids.html.

Or devise an alternate deployment method which allows for rolling restarts of servers in the replication topology.
[4 Feb 2014 16:20] Luis Soares
Related: BUG#71543.
[11 Feb 2015 14:37] Jon Stephens
This is fixed in MySQL 5.7.6 by WL#7803 'SET gtid_mode ONLINE'.