Presenting "Pseudo GTID": a competitive technology to MySQL 5.6 GTID, with less overhead and constraints, running on top of you good-old-mysql-replication topology, no upgrades or agents required. Pseudo GTID allows easy replication topology changes as well as easy recovery from master/intermediate master/slave crash.

1. Pseudo GTID & Easy
Replication Topology
Management
Shlomi Noach

2. What? Why?
Pseudo GTID is a mechanism which provides with GTID-
like behavior, and more:
● Topology refactoring; moving slaves around made easy
● Recover topology/replication from master/intermediate
master failures
● Recover replication after crash even without replication-
safe setup

3. Why not GTID?

4. Why not GTID?
● Requires 5.6 / MariaDB 10.0
● No easy migration path in 5.6
● Still issues with 5.6 GTID
● GTID incompatible between MySQL 5.6 and MariaDB;
implementations completely different
● Pseudo GTID to pose less constraints
● Pseudo GTID to deliver shorter failover times on mass
operations

5. Managing replication topologies

6. Managing large replication
topologies
● Large topologies tend to be complex
● They span multiple data centers
● Often introduce intermediate masters to reduce network
overhead
● May have specialized sub-topologies (upgraded
version; developer zone; etc.
● Introduce a new set of problems

11. Solved by Pseudo GTID

12. Solved by Pseudo GTID

14. Solved by Pseudo GTID

15. What’s the idea behind
Pseudo GTID?

16. Binary
logs

17. Binary
logs
Relay
logs

18. Binary
logs Binary
logs
Relay
logs

19. Binary
logs Binary
logs
Relay
logs

20. Binary
logs Binary
logs
Relay
logs
Inject periodic
unique
statements
(e.g. every 10
seconds)

21. Virtual
binary
log
Virtual
binary
log
Relay
logs

22. Virtual
binary
log
Virtual
binary
log
Statements
executed here,
but never got
to slave(s)
Find and last known Pseudo-GTID
statement on slave, match with that of
(soon to be) its master.
These statements are next followed by
normal application statements.

23. Virtual
binary
log
Virtual
binary
log
Statements
executed here,
but never got
to slave(s)
Compare statements after last known
Pseudo GTID, until reached end of
binary logs on slave. Then point to
matching position on master.

24. Requirements, part I
● For a slave to be able to pick up as master /
intermediate master:
○ log_bin on slaves
○ log_slave_updates on slaves
(the above two also required with 5.6 GTID)
■ For crash safe replication, add sync_binlog
● Otherwise we can utilize relay logs (hacks included)

25. How to inject a Pseudo GTID entry?
delimiter ;;
create event if not exists
meta.create_pseudo_gtid_event
on schedule every 1 second starts current_timestamp on completion preserve enable
do
begin
set @pseudo_gtid := uuid();
set @_create_statement := concat(
'drop ', 'view if exists `meta`.`_pseudo_gtid_', 'hint__', @pseudo_gtid, '`');
PREPARE st FROM @_create_statement;
EXECUTE st;
DEALLOCATE PREPARE st;
end
;;
delimiter ;

26. In the binary logs
mysql> show binlog events in 'mysql-bin.015631' G
...
Log_name: mysql-bin.015631
Pos: 1632
Event_type: Query
Server_id: 1
End_log_pos: 1799
Info: use `meta`; drop view if exists `meta`.`_pseudo_gtid_hint__50731a22-9ca4-
11e4-aec4-e25ec4bd144f`
...
These views do not exist in the first place. Statement is propagated and
uniquely identified in replication chain.

28. Efficient bulk operations
● Identify replication
groups
● Only do the math on
one slave per group
● The reset follow on
same coordinates (only
CHANGE MASTER TO
required)

29. Requirements, part II
● Single threaded replication
(also required with 5.6 GTID)
● In-order binlog statements applier on slave (true in
MariaDB and in MySQL 5.7.5 with
slave_preserve_commit_order

30. Orchestrator
● orchestrator is a MySQL replication topology manager
and visualizer
○ First developed at Outbrain
○ Development continues at Booking.com
○ Free and open source
https://github.com/outbrain/orchestrator/
● orchestrator supports Pseudo GTID
Recall that Pseudo GTID injection is an independent operation

31. When to use Pseudo GTID?
● 5 years ago!
This technology could have been invented and used ages ago
● On MySQL 5.5: “backport” GTID & crash safe
replication
● If you’re hesitant on using GTID. Pseudo GTID uses
plain-old-MySQL-replication and is non intrusive. No
changes required to your existing topologies.
● We’re working to use Pseudo-GTID as the basis for HA
solution in Booking.com

32. Thank you!
Questions?
@ShlomiNoach
http://openark.org