{"id":7854,"date":"2018-05-22T10:39:46","date_gmt":"2018-05-22T08:39:46","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=7854"},"modified":"2018-05-22T10:42:32","modified_gmt":"2018-05-22T08:42:32","slug":"mysql-master-discovery-methods-part-6-other-methods","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/mysql-master-discovery-methods-part-6-other-methods","title":{"rendered":"MySQL master discovery methods, part 6: other methods"},"content":{"rendered":"<p>This is the sixth in a series of posts reviewing methods for MySQL master discovery: the means by which an application connects to the master of a replication tree. Moreover, the means by which, upon master failover, it identifies and connects to the newly promoted master.<\/p>\n<p>These posts are not concerned with the manner by which the replication failure detection and recovery take place. I will share <code>orchestrator<\/code> specific configuration\/advice, and point out where cross DC <code>orchestrator\/raft<\/code> setup plays part in discovery itself, but for the most part any recovery tool such as <code>MHA<\/code>, <code>replication-manager<\/code>, <code>severalnines<\/code> or other, is applicable.<\/p>\n<h3>Hard coded configuration deployment<\/h3>\n<p>You may use your source\/config repo as master service discovery method of sorts.<\/p>\n<p>The master&#8217;s identity would be hard coded into your, say, <code>git<\/code> repo, to be updated and deployed to production upon failover.<\/p>\n<p>This method is simple and I&#8217;ve seen it being used by companies, in production. Noteworthy:<\/p>\n<p><!--more--><\/p>\n<ul>\n<li>This requires a dependency of <code>production<\/code> on source availability.\n<ul>\n<li>The failover tool would need to have access to your source environment.<\/li>\n<\/ul>\n<\/li>\n<li>This requires a dependency of <code>production<\/code> on build\/deploy flow.\n<ul>\n<li>The failover tool would need to kick build, test, deploy process.<\/li>\n<\/ul>\n<\/li>\n<li>Code deployment time can be long.<\/li>\n<li>Deployment must take place on all relevant hosts, and cause for a mass refresh\/reload.\n<ul>\n<li>It should interrupt processes that cannot reload themselves, such as various commonly used scripts.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h3>Synchronous replication<\/h3>\n<p>This series of posts is focused on asynchronous replication, but we will do well to point out a few relevant notes on sychnronous replication (<em>Galera<\/em>, <em>XtraDB Cluster<\/em>, <em>InnoDB Cluster<\/em>).<\/p>\n<ul>\n<li>Synchronous replication can act in single-writer mode or in multi-writer mode.<\/li>\n<li>In single writer mode, apps should connect to a particular master.\n<ul>\n<li>The identity of such master can be achieved by querying the MySQL members of the cluster.<\/li>\n<\/ul>\n<\/li>\n<li>In multi-writer mode, apps can connect to any healthy member of the cluster.\n<ul>\n<li>This still calls for a check: is the member healthy?<\/li>\n<\/ul>\n<\/li>\n<li>Syncronous replication is not intended to work well cross DC.<\/li>\n<\/ul>\n<p>The last bullet should perhaps be highlighted. In a cross-DC setup, and for cross-DC failovers, we are back to same requirements as with asynchronous replication, and the methods illustrated in this series of posts may apply.<\/p>\n<ul>\n<li>VIPs make less sense.<\/li>\n<li>Proxy-based solution make a lot of sense.<\/li>\n<\/ul>\n<h3>All posts in this series<\/h3>\n<ul>\n<li><a href=\"http:\/\/code.openark.org\/blog\/mysql\/mysql-master-discovery-methods-part-1-dns\">MySQL master discovery methods, part 1: DNS<\/a><\/li>\n<li><a href=\"http:\/\/code.openark.org\/blog\/mysql\/mysql-master-discovery-methods-part-2-vip-dns\">MySQL master discovery methods, part 2: VIP &amp; DNS<\/a><\/li>\n<li><a href=\"http:\/\/code.openark.org\/blog\/mysql\/mysql-master-discovery-methods-part-3-app-service-discovery\">MySQL master discovery methods, part 3: app &amp; service discovery<\/a><\/li>\n<li><a href=\"http:\/\/code.openark.org\/blog\/mysql\/mysql-master-discovery-methods-part-4-proxy-heuristics\">MySQL master discovery methods, part 4: Proxy heuristics<\/a><\/li>\n<li><a href=\"http:\/\/code.openark.org\/blog\/mysql\/mysql-master-discovery-methods-part-5-service-discovery-proxy\">MySQL master discovery methods, part 5: Service discovery &amp; Proxy<\/a><\/li>\n<li><a href=\"http:\/\/code.openark.org\/blog\/mysql\/mysql-master-discovery-methods-part-6-other-methods\">MySQL master discovery methods, part 6: other methods<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>This is the sixth in a series of posts reviewing methods for MySQL master discovery: the means by which an application connects to the master of a replication tree. Moreover, the means by which, upon master failover, it identifies and connects to the newly promoted master. These posts are not concerned with the manner by [&hellip;]<\/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":[],"class_list":["post-7854","post","type-post","status-publish","format-standard","hentry","category-mysql"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-22G","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7854","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=7854"}],"version-history":[{"count":6,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7854\/revisions"}],"predecessor-version":[{"id":7904,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7854\/revisions\/7904"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=7854"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=7854"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=7854"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}