89571

Using GTlDs for Failover and Scaleout

There are a number of techniques when using MySQL Replication with Global Transaction Identifiers

(GTlDs) in MySQL 5.6.9 and later for provisioning a newslave which can then be used for scaleout,

being promoted to master as necessary for failover. In this section, we discuss the four techniques listed here:

•    Simple replication

•    Copying data and transactions to the slave

•    Injecting empty transactions

•    Excluding transactions with gtid_purged

Global transaction identifiers were added to MySQL Replication for the purpose of simplifying in

generał management of the replication data flowand of failover activities in particular. Each identifier

uniquely identifies a set of binary log events that together make up a transaction. GTlDs play a key role

in applying changes to the database: the server automatically skips any transaction having an identifier

which the server recognizes as one that it has processed before. This behavior is critical for automatic

replication positioning and correct failover.

The mapping between identifiers and sets of events comprising a given transaction is captured in the

binary log. This poses some challenges when a user wants to provision a newserver with data from

another existing server. To reproduce the identifier set on the newserver, it is necessary, not only

to copy the identifiers from the old server to the new one, but to preserve the relationship between

the identifiers and the actual events as well, which is what is needed for restoring a slave that is

immediately available as a candidate to become a new master on failover or switchover.