How MHA Delivers Fast, Zero‑Data‑Loss MySQL High Availability

MHA Introduction

MHA (MySQL High Availability) is a mature HA solution created by Japanese engineer youshimaton (formerly of DeNA, now at Facebook). It can complete a failover in about 30 seconds while maximizing data consistency, and a similar product (TMHA) is being developed by Taobao.

MHA Architecture

MHA consists of a Manager and multiple Nodes . The Manager runs tools such as masterha_manager to monitor MySQL masters and orchestrate failover, and one Manager can control many master‑slave clusters. Nodes are deployed on every MySQL server—both masters and slaves.

Each Node performs three main tasks:

Preserve binary logs by copying them from a reachable failed master.

Generate and apply differential relay logs from the most up‑to‑date slave.

Clean relay logs without stopping the SQL thread.

MHA Working Principle

When the master crashes, Nodes compare the I/O thread positions of all slaves, select the slave closest to the master’s binlog as the “latest slave”, and generate differential relay logs on the other slaves. The latest slave applies the saved master binlog and is promoted to master; the remaining slaves then apply their differential logs and resume replication from the new master.

If the failed master is still reachable via SSH (i.e., not a hardware failure), its binary logs are saved to minimize data loss. Combining MHA with semi‑synchronous replication further reduces the risk of data loss.

Current High‑Availability Solutions

Heartbeat + DRBD : Requires an extra passive master server; performance degrades because InnoDB flush settings must be set to 1.

MySQL Cluster : Provides true HA using the NDB engine but introduces a single point of failure at the SQL node.

Semi‑synchronous Replication (5.5+) : Reduces the “binlog only on failed master” problem but may leave some slaves without the latest binlog.

Global Transaction ID : Needs binlog format changes not supported in MySQL 5.1/5.5; adds complexity and potential performance issues.

PXC (Percona XtraDB Cluster) : Offers concurrent replication and HA but only works with InnoDB, requires primary keys, and can suffer from lock conflicts and deadlocks.

MHA Advantages

Fast failover : Typically 10‑30 seconds downtime; DeNA reported a 4‑second failover across >150 MySQL instances.

No data inconsistency : Detects and applies relay‑log differences to all slaves; when combined with semi‑synchronous replication, data loss is virtually eliminated.

No MySQL configuration changes : Works with native MySQL 5.0+ replication without altering existing setups.

Minimal additional servers : Only one Manager server is needed; Nodes run on existing MySQL hosts.

No performance impact : Manager pings masters every few seconds without heavy queries, matching native replication performance.

Engine‑agnostic : Supports any storage engine that can run MySQL replication, including MyISAM.

Additional Notes

MHA operates on native MySQL versions from 5.0 onward, so legacy deployments do not need migration to newer engines or storage formats. Upgrading MHA is as simple as replacing the binaries and restarting the Manager, without stopping MySQL.