Skip to content

# MySQL master discovery methods, part 6: other methods

MySQL May 22, 2018May 22, 2018

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 which the replication failure detection and recovery take place. I will share `orchestrator` specific configuration/advice, and point out where cross DC `orchestrator/raft` setup plays part in discovery itself, but for the most part any recovery tool such as `MHA`, `replication-manager`, `severalnines` or other, is applicable.

### Hard coded configuration deployment

You may use your source/config repo as master service discovery method of sorts.

The master’s identity would be hard coded into your, say, `git` repo, to be updated and deployed to production upon failover.

This method is simple and I’ve seen it being used by companies, in production. Noteworthy:

- This requires a dependency of `production` on source availability.
  - The failover tool would need to have access to your source environment.
- This requires a dependency of `production` on build/deploy flow.
  - The failover tool would need to kick build, test, deploy process.
- Code deployment time can be long.
- Deployment must take place on all relevant hosts, and cause for a mass refresh/reload.
  - It should interrupt processes that cannot reload themselves, such as various commonly used scripts.

### Synchronous replication

This series of posts is focused on asynchronous replication, but we will do well to point out a few relevant notes on sychnronous replication (Galera, XtraDB Cluster, InnoDB Cluster).

- Synchronous replication can act in single-writer mode or in multi-writer mode.
- In single writer mode, apps should connect to a particular master.
  - The identity of such master can be achieved by querying the MySQL members of the cluster.
- In multi-writer mode, apps can connect to any healthy member of the cluster.
  - This still calls for a check: is the member healthy?
- Syncronous replication is not intended to work well cross DC.

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.

- VIPs make less sense.
- Proxy-based solution make a lot of sense.

### All posts in this series

- MySQL master discovery methods, part 1: DNS
- MySQL master discovery methods, part 2: VIP & DNS
- MySQL master discovery methods, part 3: app & service discovery
- MySQL master discovery methods, part 4: Proxy heuristics
- MySQL master discovery methods, part 5: Service discovery & Proxy
- MySQL master discovery methods, part 6: other methods

- Twitter
- LinkedIn
- WhatsApp
- Email
- Facebook
- Print

###
1
Leave a Reply

1 Comment threads
0 Thread replies
0 Followers
Most reacted comment
Hottest comment thread
1 Comment authors
Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe
Notify of
Guest
Donatas Abraitis

How about another one method to “elect” the master node? Like here http://blog.donatas.net/blog/2017/02/26/exazk/

wpDiscuz
Send to Email Address Your Name Your Email Address Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.