Orchestrator release 1.2.7-beta now supports semi-automatic slave promotion to master upon master death, via Pseudo GTID.
When the master is dead, orchestrator automatically picks the most up-to-date slaves and marks them as “Master candidates”. It allows a /api/make-master call on such a slave (S), in which case it uses Pseudo GTID to enslave its siblings, and set S as read-only = 0. All we need to do is click the “Make master” button.
Yes, “OK”. A moment later:
See how the two slaves 22988, 22989 are happily replicating from 22990. Turning them into 22990‘s slave was possible even though their shared master was dead and were stopped at different replication positions.
22990 is now writeable, and its on you to disconnect from its old master and to direct your application into this newly promoted instance.
Local master promotion
Likewise, a semi-automated solution for the corruption of a local master is in place. Consider the following, where 22989 is dead/inaccessible. 22988 and 22990 are stuck in replication:
Orchestrator detects this situation and picks the most up-to-date slave, marking it as candidate for promotion. Click “Make lock master” to get:
Sure, OK:
And now 22990 takes over instead of 22989, enslaving 22988, both running happily ever after.
Automation
The above buttons are just convenience methods. You don’t strictly need visualization/GUI for that. Everything is supported by the API, and can be used by a fully automated monitoring system. More to come in orchestrator.
why is the example all using localhost but just on different ports?
@joseph,
Since this is my local testing environment (also where the unit tests execute).
I wanted to avoid exposing our production machines names and details.