Add config option gtid_deployment_step for GTID's deployment

Registered by Vlad Lesin on 2015-01-05

Port the code for gtid's deployment from FaceBook branch https://github.com/facebook/mysql-5.6.

With gtid_deployment_step enabled, a host cannot generate gtids on its
 own, but if gtid logged events are received through replication stream
 from master, gtids will be logged.

The gtid deployment procedure can be done with the following steps:

1) replicas: gtid_mode = ON and gtid_deployment_step = ON
    master: gtid_mode = OFF and gtid_deployment_step = OFF

On each replica, one at a time, restart MySQL to enable gtid_mode and gtid_deployment_step. Afterward, we are in a state where every replica has gtid_mode=ON and gtid_deployment_step=ON, but the master still has gtid_mode=OFF and gtid_deployment_step=OFF.

2) new master: gtid_mode = ON and gtid_deployment_step = OFF
    rest replicas: gtid_mode = ON and gtid_deployment_step = ON
    old master: gtid_mode = OFF and gtid_deployment_step = OFF

Perform a master promotion as normal, i.e. gtid_mode=ON and gtid_deployment_step=OFF, repointing the replicas and original master to a new master. The original master's replication will intentionally break when started, since it still has gtid_mode = OFF and gtid_deployment_step = OFF.

3) new master: gtid_mode = ON and gtid_deployment_step=OFF
    rest replicas: gtid_mode = ON
    old master: gtid_mode = ON

Restart the original master to enable gtid_mode. It will now be able to replicate from the new master, and the entire replica set now has gtid_mode=ON. Set gtid_deployment_step=OFF in config file on each replica and restart them when necessary.

The original description can be found here: https://www.facebook.com/notes/mysql-at-facebook/lessons-from-deploying-mysql-gtid-at-scale/10152252699590933 .

UPD:

gtid_deployment_step is dynamic variable now, so there is no need to restart server to change it.

The conditions for dynamic switching gtid_deployment_step off are the same as for read_only (see http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_read_only):

1) If you attempt to enable read_only while you have any explicit locks (acquired with LOCK TABLES) or have a pending transaction, an error occurs.

2) If you attempt to enable read_only while other clients hold explicit table locks or have pending transactions, the attempt blocks until the locks are released and the transactions end. While the attempt to enable read_only is pending, requests by other clients for table locks or to begin transactions also block until read_only has been set.

The operation of dynamically going gtid_deployment_step from off to on is not supported.

Blueprint information

Status:
Complete
Approver:
Laurynas Biveinis
Priority:
High
Drafter:
Vlad Lesin
Direction:
Approved
Assignee:
Vlad Lesin
Definition:
Approved
Series goal:
Accepted for 5.6
Implementation:
Implemented
Milestone target:
milestone icon 5.6.22-72.0
Started by
Laurynas Biveinis
Completed by
Laurynas Biveinis

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.