Understanding MHA: Master High Availability for MySQL Clusters

What is MHA?

MHA (Master High Availability) is used to ensure high availability of MySQL clusters. It monitors the master, and when a master failure is detected, it automatically performs failover, elects a new master from the slaves, and synchronizes other slaves with the new master.

The main feature is fast fault handling, maximizing data loss prevention.

How It Works

When the master fails, MHA quickly rescues data by attempting to retrieve binary logs from the master; if the failure is not physical, this usually succeeds.

A new master is elected based on which slave holds the most recent data.

After identifying the latest slave, other slaves compare their data with it, generating differential logs.

If binary logs are successfully obtained from the failed master, they are replayed on the latest slave to ensure data consistency.

The latest slave is then promoted to the new master.

Other slaves apply the corresponding differential logs and start replicating from the new master.

Advantages

Fast fault handling – typically completed within 30 seconds.

Good data safety – slaves use differential logs to maintain consistency, and with semi‑synchronous replication, data loss is almost eliminated.

Easy extensibility – developed in Perl, open source, with open interfaces supporting extensions in other languages; modifying existing code or adding new features is straightforward.

Multi‑cluster monitoring – a single MHA manager can oversee multiple clusters.

Disadvantages

Only monitors the master; slave issues such as replication breaks or increased lag are not detected.

Lacks built‑in virtual IP configuration; a VIP must be set up manually for transparent failover.

Security concerns – requires password‑less SSH between servers, which can pose risks if any server is compromised.

MHA is a mature high‑availability solution; this overview provides a basic understanding before diving into detailed configuration.