MHA Re-Edition: Modern MySQL HA with GTID Failover and Auto Switch

Tool Overview

MHA Re-Edition is a rebuilt version of the original mha4mysql-manager that adds GTID-based replication support and simplifies deployment for MySQL 5.7/8.0 master-slave clusters.

Key Improvements

No SSH key trust required; MySQL root credentials are supplied in app1.cnf to allow the tool to move the virtual IP (VIP) directly.

Supports GTID-based replication, eliminating the need to specify binlog file and position.

Only two executables are needed: masterha_check_repl_mysql (environment check) and masterha_manager_mysql (auto-failover and online switch).

Runs only on GTID-enabled setups; aborts on binlog/position-based configurations. Optional semi-synchronous replication can be enabled.

Integrated functions: master switch, VIP failover, secondary check, shutdown script, and optional WeChat alarm.

Supports remote-management-card reboot (e.g., IPMI) when VIP removal fails.

Configuration File (app1.cnf) Parameters

manager_workdir = /root/mha_log/app1.log

– log file location. connect_interval = 1 – seconds between connection attempts to the master. masterha_secondary_check = slave1,slave2 – list of secondary servers to probe when the master is unreachable. running_updates_limit = 60 – if a slave lags more than 60 seconds, force VIP failover.

shutdown_script = ipmitool -I lanplus -H 172.31.198.239 -U root -P calvin power reset

– command to reboot the host via IPMI when VIP removal fails. weixin_alarm = /usr/bin/python wechat.py yourweixin – path to the WeChat alert script (requires simplejson).

Deployment Steps

Make the check binary executable and run the environment check:

chmod 755 masterha_check_repl_mysql
./masterha_check_repl_mysql --conf=app1.cnf

Start the manager daemon:

chmod 755 masterha_manager_mysql
./masterha_manager_mysql --conf=app1.cnf start

Perform an online master switch when needed: ./masterha_manager_mysql --conf=app1.cnf switch Multiple app1.cnf files can be used to monitor several MySQL clusters simultaneously.

Auto-Failover Logic

The manager attempts to connect to the master every connect_interval seconds. After three consecutive failures it probes the servers listed in masterha_secondary_check. If any secondary can connect, the master is considered alive and a warning is logged; otherwise the master is deemed down and failover proceeds.

If candidate_master = 1 is set, the specified candidate becomes the new master; otherwise the slave with the most recent GTID events is promoted.

When a slave’s replication lag exceeds running_updates_limit, the tool forces VIP migration, sets the old master to read-only, kills its client connections, and applies a global read lock before promotion.

Online Switch Procedure

Verify health of the current master and all slaves.

Execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master.

Confirm the target slave for promotion (the tool prompts for confirmation).

Remove the VIP from the old master.

Set the old master to read-only ( SET GLOBAL read_only=1).

Kill all client connections on the old master.

Apply a global read lock ( FLUSH TABLES WITH READ LOCK).

On the candidate master, wait for GTID execution to finish (or force switch if lag exceeds running_updates_limit).

Set the new master to read-write ( SET GLOBAL read_only=0).

Execute CHANGE MASTER TO on the remaining slaves to point to the new master.

Unlock tables on the old master.

Stop the slave process on the new master (do not run RESET SLAVE ALL – user must handle it).

Move the VIP to the new master.

Finish the switch.

Download

The source code is available at: https://github.com/hcymysql/MHA-Re-Edition Optional WeChat alarm script documentation:

https://github.com/X-Mars/Zabbix-Alert-WeChat/blob/master/README.md