Choosing the Right MySQL HA Architecture: Master‑Slave, Dual‑Master, Heartbeat+DRBD, and GTID

Single Master‑Slave

In a one‑master‑one‑slave setup, all traffic is redirected to a new master when the original master fails, simplifying failover. However, this architecture cannot scale read traffic, and a single point of failure remains because the sole slave must handle backups, analytics, and batch jobs, leading to performance bottlenecks and prolonged recovery times.

Dual Master‑Multiple Slaves

A dual‑master configuration provides a standby master that can take over when the primary fails, often set as read‑only. Yet consistency issues persist because slaves may not have received the latest relay logs, requiring additional mechanisms to resolve divergence. The approach also suffers from the same read‑scaling limitations and adds complexity, typically requiring at least four servers.

Heartbeat + DRBD

Combining Heartbeat (active/passive clustering) with DRBD (block‑level replication) is a popular HA solution, but it introduces several challenges:

Resource overhead: A passive master cannot serve read traffic, so a minimum of four MySQL instances (active master, passive master, two slaves) is needed.

Failover latency: Switching to the passive node can take minutes, especially without the InnoDB plugin, and the new master must warm up caches, temporarily degrading write performance.

Write performance and consistency: To guarantee safety, innodb-flush-log-at-trx-commit=1 and sync-binlog=1 are required, which reduces throughput. If sync-binlog is disabled, a failover may lose binlog events, causing replication gaps.

Operational complexity: Installing and configuring Heartbeat and DRBD demands kernel‑level expertise; mistakes (e.g., running drbd --overwrite-data-of-peer on the passive node) can corrupt production data.

MySQL Cluster

MySQL Cluster offers true HA but requires the NDB storage engine, which is rarely used in favor of InnoDB, limiting its practical adoption.

Semi‑Synchronous Replication

Semi‑sync replication reduces the risk of losing binlog data by ensuring at least one slave acknowledges receipt of each transaction before the master commits. It still does not guarantee full consistency because some slaves may lag behind, leaving them out of sync.

Global Transaction ID (GTID)

GTID provides a unified identifier for each transaction, enabling multi‑level replication recovery. Unlike MHA, which supports only two replication layers, GTID can handle many layers, allowing recovery even when intermediate slaves fail. MySQL 5.6+ supports GTID, and tools such as Oracle's mysqlfailover and MHA 0.56+ can perform GTID‑aware failover automatically.

Overall, selecting a MySQL HA solution involves balancing scalability, recovery time, operational complexity, and consistency guarantees.