Database High‑Availability Architectures: Master‑Slave, Master‑Master, and Automatic Failover

Having read many high‑availability designs for application services, let’s explore high‑availability for databases.

Database high‑availability solutions achieve redundancy by replicating data across multiple storage devices, using architectures such as master‑slave, master‑master, clustering, and partitioning; the article discusses each topology’s pros and cons.

Master‑Slave Architecture

Basic topology diagram (image omitted for brevity).

The architecture is simple; most databases (MySQL, Oracle, MongoDB, etc.) support master‑slave replication. The standby node only stores backups and does not handle read/write traffic; promotion to primary requires manual intervention.

Advantages and disadvantages.

Clients are unaware of the standby; after disaster recovery, only the connection address changes, no application changes needed.

Only data copy is needed; no state‑checking or switch‑over logic.

Disadvantages:

If there is no read‑write separation, the standby is a wasted resource.

Failover requires manual steps, which are slow and error‑prone.

Master‑Slave Architecture (Read‑Write Separation)

Unlike master‑slave, the slave participates in read operations, requiring the application to separate reads from writes.

Basic topology diagram (image omitted).

Advantages and disadvantages.

Advantages:

Read traffic can continue when the master fails.

Slaves provide read capacity, leveraging hardware performance.

Different slaves can serve different roles.

Disadvantages:

Replication lag may cause data inconsistency.

Application complexity increases due to read‑write separation.

Failover still requires manual intervention.

Automatic Master‑Slave Failover

Both previous architectures share two problems: writes are impossible when the master fails, and manual promotion of a slave is required, which can be delayed or faulty.

To address this, an automatic failover mechanism is needed, typically involving a third‑party mediator that monitors node health and triggers promotion without human involvement.

Advantages:

Eliminates manual intervention, reducing downtime and protecting operations staff.

Disadvantages:

Increased complexity and the need to ensure high‑availability of the mediator.

Recommended solutions include MySQL MHA or building a custom failover using Zookeeper or Keepalived.

Master‑Master Architecture

In master‑master (dual‑master) replication, both nodes act as primaries, replicating to each other, allowing clients to read or write to either node.

Advantages over failover setups:

No concept of promotion; both nodes are always primary.

Clients need not distinguish roles; any node can handle read/write.

Architecture is simple.

Risks:

Auto‑increment primary keys can collide (e.g., both nodes generate ID 1).

Concurrent updates can cause divergent data; for example, table tb with column col where one node runs update tb set col = col + 1 and the other runs update tb set col = col * 2 , resulting in inconsistent values (4 vs 3) without replication errors.

Therefore, master‑master requires strict data design and is suitable only for temporary, overwrite‑able data scenarios.

Hope this helps!