MySQL master discovery methods, part 6: other methods

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