I attended the session titled “Pseudo GTID and easy replication management” by Shlomi Noach from Booking.com.  In this session Shlomi went over replication, GTID, then Pseudo GTID and some demos.

Pseudo GTID provides:

• Slave repointing
• Failover schemas
• less requirements

Binary logs are pulled by the slave where it is written to the slaves relay logs.  Nothing ties these two together.  They can be flushed at different times, etc.  With log slave updates the relay logs are written to the slaves binary logs.  The problem only grows when you add multiple slaves and relay slaves.  GTID has the following properties

• Every transaction has a unique identifier
• When slave connects it looks for last GTID it already executed
• Requires log slave updates (fixed in 5.7) on all slaves (Disk I/O)
• Migration is all at once (master and slaves all at the same time)
• Oracle GTID and MariaDB GTID are different implementations so can cause vendor lock-in

Pseudo GTID is an application side enhancement.  The application injects every few seconds which you can uniquely identify.  It is like “tracer tokens” in SQL Server replication.  This gives you something to measure where the tracer is in your environment.  This gives you information you can use to more easily identify how to reconnect a slave to a master.

Then Shlomi went over a tool called Orchestrator that is topology aware to help you manage replication.  Works with command line or web api.  He killed a live server as part to the demo.  That is some confidence in your tool and your presentation.  With Pseudo GTID it can automatically move slaves to a new candidate master based on a number of different factors.  Pretty impressive.