Appendix B. A GTID Implementation
With MySQL 5.6, global transaction identifiers were introduced to provide a way to uniquely identify a transaction regardless of what server it is executed on. Handling failovers with a 5.6 server is very easy, and you can find a description of that in Failover Using GTIDs. But if you do not have a 5.6 server and still need to perform failover, you can use the methods described in this appendix, basically by implementing your own global transaction identifiers and writing them to the binary log. The goal is to implement the features necessary to perform slave promotion.
Adding GTIDs to a Server
To match the latest transaction on each of the slaves with the corresponding event in the binary log of the promoted slave, you need to tag each transaction. The content and structure of the tags don’t matter; they just need to be uniquely identifiable no matter who executed the transaction so each transaction on the master can be found in the promoted slave’s binary log. These tags are the global transaction identifiers that we are going to implement in this appendix.
The easiest way to accomplish this is to insert a statement at the end of each transaction that updates a special table and use that to keep track of where each slave is. Just before committing each transaction, a statement updates the table with a number that is unique for the transaction.
Tagging can be handled in two main ways:
Extending the application code to perform the necessary statements ...
Get MySQL High Availability, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.