Simplify MySQL HA with MariaDB MaxScale: Consul‑MHA Alternative and Step‑by‑Step Setup

Traditional MHA (Master High Availability) is widely used in small‑to‑medium companies, but many cloud providers do not support virtual IPs, making VIP‑based failover impossible. To address this, the author proposes a Consul‑based service discovery combined with MHA, then introduces MariaDB MaxScale 2.2/2.5 as an all‑in‑one solution that eliminates third‑party tools.

Why MaxScale?

MaxScale integrates Consul and MHA functions, offering automatic failover, switchover, and rejoin for GTID‑based replication topologies (single master with multiple slaves). It provides a GUI web console and supports read‑write splitting.

Key Features and Limitations

Failover and switchover only work with GTID replication and simple one‑master‑many‑slaves topology.

Enable semi‑synchronous replication (parameter rpl_semi_sync_master_wait_point=AFTER_SYNC) to avoid data loss.

All MySQL nodes must have log_slave_updates=ON.

Installation Steps

Download and extract MaxScale 2.5.1 for CentOS 7, create a dedicated user/group, and set up directories.

Create a secret key file with maxkeys and generate an encrypted password using maxpasswd (example:

5CD3AF1688D20ECED2BECEF15C075BC6B02375FE27FFCAC3A12A5FFCBE4FB16C

).

Increase system limits (nofile 65535) and kernel parameters (file‑max, port range, tcp_tw_reuse).

Create a monitoring user with replication and super privileges (adjusted for MariaDB 10.5 permission names).

Configure maxscale.cnf with five sections: global template, server templates, MariaDB-Monitor, service template ( RW_Split_Router), and listener template ( RW_Split_Listener). Important parameters include auto_failover=true, auto_rejoin=true, failcount=3, failover_timeout=90, verify_master_failure=true, and read‑write split settings such as master_accept_reads=true, max_slave_replication_lag=1, causal_reads=local, causal_reads_timeout=10.

Start MaxScale with

/usr/local/maxscale/bin/maxscale --user=maxscale --basedir=/usr/local/maxscale/ --config=/usr/local/maxscale/etc/maxscale.cnf

. Logs are written to /usr/local/maxscale/var/log/maxscale/maxscale.log.

Use maxctrl commands to list servers and services, or access the GUI at http://<em>your_ip</em>:8989 (admin/mariadb).

Failover Scenarios

Automatic Failover : MaxScale selects the newest slave based on GTID positions, checks failover_timeout, promotes it to master, and re‑configures remaining slaves.

Manual Failover : Triggered via maxctrl call command mariadbmon failover MariaDB-Monitor, following the same selection logic.

Switchover (Online) : Use

maxctrl call command mariadbmon switchover MariaDB-Monitor server2 server1

to gracefully switch roles, ensuring the old master is set read‑only, super‑user connections are killed, tables are flushed, and GTID positions are synchronized before the switch.

Conclusion

Deploying at least two MaxScale instances (optionally behind a cloud SLB) provides a lightweight, automated HA layer for MariaDB/MySQL clusters, reducing operational complexity and eliminating the need for separate MHA and Consul deployments. Note that the latest MaxScale versions only support GTID‑based failover for MariaDB, not MySQL or Percona.