Using GTIDs for Failover and Scaleout-opracowanie

Using GTIDs for Failover and Scaleout
There are a number of techniques when using MySQL Replication with Global Transaction Identifiers
(GTIDs) in MySQL 5.6.9 and later for provisioning a new slave 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
general management of the replication data flow and of failover activities in particular. Each identifier
uniquely identifies a set of binary log events that together make up a transaction. GTIDs 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 new server with data from
another existing server. To reproduce the identifier set on the new server, 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.
... zobacz całą notatkę