This document discusses using the relay log as a solution for failover in a multi-source replication scenario where the binary log positions and transaction IDs are different across slaves. The relay log contains the same position and transaction ID for a transaction on all slaves, allowing one to be used as a global transaction ID for failover. Specifically, a modified client was created to dump the relay log, and the MySQL server was updated to support relay log dumping, providing a hero - the unsung relay log - for high availability when GTIDs were not available.

1. “a hero. not the one we
deserved, but the one we
needed - the unsung hero”
vishnu rao - flipkart.com

2. The scenario :
Multi source replication

3. The scenario :
Multi source replication

4. Failure scenario!

5. Failure scenario!

6. Failover ?
§ Can’t simply failover to other slave.
§ For Txn-1 Binlog Positions are
different across the slaves ( p2 p3 )
§ Xid’s of Txn-1 are different across the
slaves ( xid 2 xid 3 )
§ i.e. absence of GTID.

7. What now ?

8. Signal the relay log !

9. The Relay log
§ The relay log on each slave is a copy
of the master’s binlog.
§ Position Xid of Transaction Txn-1
in the relay log are SAME on both
slaves.
§ i.e. we now have Global Transaction
ids

10. The solution:
‘replicate via relay log’

11. The solution:
‘replicate via relay log’...

12. The solution:
‘replicate via relay log’...

13. The solution:
‘replicate via relay log’...

14. The solution:
‘replicate via relay log’...

15. code/
§ Modified ‘Tungsten’ client which sends
‘com_relaylog_dump’
§ MySQL server – com_relaylog_dump
for relay log dump functionality
@
github.com/jaihind213/mash213

16. § 5.6 – GTID -The hero we deserved
§ 5.5 – Relay log – The hero we needed

17. Relay log - the unsung hero.
Thank you.
jaihind213@gmail.com / vishnuhr@flipkart.com
mash213.wordpress.com
doodle-vishnu.blogspot.in
in.linkedin.com/in/213vishnu
sweetweet213@twitter