{"id":7119,"date":"2014-11-10T07:56:58","date_gmt":"2014-11-10T05:56:58","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=7119"},"modified":"2014-11-10T07:56:58","modified_gmt":"2014-11-10T05:56:58","slug":"semi-automatic-slavemaster-promotion-via-pseudo-gtid","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/semi-automatic-slavemaster-promotion-via-pseudo-gtid","title":{"rendered":"Semi-automatic slave\/master promotion via Pseudo GTID"},"content":{"rendered":"

Orchestrator<\/a> release 1.2.7-beta<\/a> now supports semi-automatic slave promotion to master upon master death, via Pseudo GTID<\/a>.<\/p>\n

\"orchestrator-make-master-highlighted\"<\/a><\/p><\/blockquote>\n

When the master is dead, orchestrator<\/em> automatically picks the most up-to-date slaves and marks them as “Master candidates”<\/strong>. It allows a \/api\/make-master<\/strong> call on such a slave (S), in which case it uses Pseudo GTID<\/a> to enslave its siblings, and set S as read-only = 0<\/strong>. All we need to do is click the “Make master”<\/strong> button.<\/p>\n

\"orchestrator-make-master-confirm\"<\/a><\/p><\/blockquote>\n

Yes, “OK”<\/strong>. A moment later:<\/p>\n

\"orchestrator-make-master-refactored\"<\/a><\/p><\/blockquote>\n

See how the two slaves 22988<\/strong>, 22989<\/strong> are happily replicating from 22990<\/strong>. Turning them into 22990<\/strong>‘s slave was possible even though their shared master was dead and were stopped at different replication positions.<\/p>\n

22990<\/strong> is now writeable, and its on you to disconnect from its old master and to direct your application into this newly promoted instance.<\/p>\n

Local master promotion<\/h4>\n

Likewise, a semi-automated solution for the corruption of a local master is in place. Consider the following, where 22989<\/strong> is dead\/inaccessible. 22988<\/strong> and 22990<\/strong> are stuck in replication:<\/p>\n

\"orchestrator-make-local-master\"<\/a><\/p><\/blockquote>\n

Orchestrator<\/em> detects this situation and picks the most up-to-date slave, marking it as candidate for promotion. Click “Make lock master”<\/strong> to get:<\/p>\n

\"orchestrator-make-local-master-confirm\"<\/a><\/p><\/blockquote>\n

Sure, OK:<\/p>\n

\"orchestrator-make-local-master-refactored\"<\/a><\/p><\/blockquote>\n

And now 22990<\/strong> takes over instead of 22989<\/strong>, enslaving 22988<\/strong>, both running happily ever after.<\/p>\n

\u00a0Automation<\/h4>\n

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<\/em>.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

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, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[5],"tags":[108,115,8],"class_list":["post-7119","post","type-post","status-publish","format-standard","hentry","category-mysql","tag-orchestrator","tag-pseudo-gtid","tag-replication"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-1QP","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=7119"}],"version-history":[{"count":14,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7119\/revisions"}],"predecessor-version":[{"id":7170,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7119\/revisions\/7170"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=7119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=7119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=7119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}