Overview

History

replication-manager was initially written with the goal of closing the gap between Galera Cluster and MySQL Master HA. While Galera Cluster is a really good product, it has some shortcomings such as performance and cluster-wide locking. replication-manager is a tailored solution on top of existing technologies in MySQL and MariaDB such as Global Transaction ID, Semi-Sync Replication, Binary log Flashback, that aims to provide High Availability and Node Switchover without compromising the performance by a too large factor. It also aims to be configurable and user-friendly by offering an HTML interface and interaction with familiar database proxying software.

Workflow

To perform switchover, preserving data consistency, replication-manager uses an improved workflow similar to common MySQL failover tools such as MHA:

  • [x] Verify replication settings
  • [x] Check (configurable) replication on the slaves
  • [x] Check for long running queries and transactions on master
  • [x] Elect a new master (default to most up to date, but it could also be a designated candidate)
  • [x] Put down the IP address on master by calling an optional script
  • [x] Reject writes on master by calling FLUSH TABLES WITH READ LOCK
  • [x] Reject writes on master by setting READ_ONLY flag
  • [x] Reject writes on master by decreasing MAX_CONNECTIONS
  • [x] Kill pending connections on master if any remaining
  • [x] Watching for all slaves to catch up to the current GTID position
  • [x] Promote the candidate slave to be a new master
  • [x] Put up the IP address on new master by calling an optional script
  • [x] Switch other slaves and old master to be slaves of the new master
  • [x] Set slave read-only

Traffic routing

replication-manager is commonly used as an arbitrator with a layer that routes the database traffic to the leader database node (aka the MASTER):

  • [x] Layer 7 proxy as ProxySQL OR MariaDB MaxScale that can transparently follow a newly elected topology
  • [x] Layer 4 proxy, replication-manager can reload a new configuration with the new route. A common scenario is a VRRP Active Passive HAProxy sharing his configuration via a network disk or collocation of the proxy with replication-manager. Some other architecture components can be already in charge of the GCC.
  • [x] Layer 4 proxy using replication-manager as an API. replication-manager can be called as a resource instructing the routing service on the states of the nodes, this is the case for haproxy external checks.
  • [x] DNS routing, replication-manager will update some discovering service like consul or DNS to enable direct routing without proxying.