Master-slave vs Master-master

DatabasesSeniordb

The Question

What is the difference between master-slave and master-master replication?

What a Strong Answer Covers

• SPOF for master-slave
• write conflicts for master-master.

Senior-Level Answer

Database replication strategies fundamentally differ in where writes are accepted, which drives everything from consistency guarantees to operational complexity.

**Master-slave replication** (also called primary-replica) designates a single node as the write target. All writes go to the master; changes are replicated asynchronously (or semi-synchronously) to one or more slaves. Slaves serve read traffic, providing horizontal read scaling. Failover requires promoting a slave to master — a non-trivial operation that must ensure the promoted slave has applied all pending replication events to avoid data loss. This topology is simple to reason about: there is exactly one authoritative state at any point in time, so there are no write conflicts.

The downsides are write throughput ceiling (single write node), and if the master fails before replication completes, the acknowledged writes on the master but not yet replicated are lost — this is the **replication lag** window of data loss. Semi-synchronous replication (MySQL's `rpl_semi_sync`) waits for at least one slave to acknowledge before committing, reducing but not eliminating this window.

**Master-master replication** (multi-primary) allows writes to be accepted by multiple nodes simultaneously. Each node replicates its writes to all other masters. This provides write fault tolerance (any master can fail and writes continue) and potentially lower write latency (clients can write to the nearest node). These benefits come with a fundamental challenge: **write conflicts**. If two masters concurrently update the same row, the system must detect and resolve the conflict — either with last-write-wins (risky), application-level conflict resolution, or CRDTs for specific data types.

In practice, true multi-primary systems are difficult to operate correctly. Tools like MySQL Group Replication and Galera Cluster implement synchronous multi-primary with a distributed consensus protocol (Paxos / Totem) to prevent conflicts at commit time, at the cost of cross-node coordination latency on every write. CockroachDB and Vitess extend this to globally distributed deployments.

For most OLTP workloads, master-slave with read replicas and a robust failover tool (Patroni for PostgreSQL, Orchestrator for MySQL) is the right choice. Master-master is warranted for active-active geo-distribution where write latency to a single region is unacceptable.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Claiming master-slave has no SPOF without qualifying that the master itself is a SPOF for writes.
• Underestimating the complexity of conflict resolution in master-master — 'last write wins' is often data loss in disguise.
• Not mentioning replication lag and its impact on read-your-writes consistency from slaves.
• Conflating master-master with sharding — they are orthogonal strategies.

Follow-Up Questions

• How does Patroni handle automatic failover in a PostgreSQL master-slave cluster? — Patroni uses etcd/Consul/ZooKeeper for distributed consensus on leader election; promotes the most up-to-date replica and updates the DCS lock.
• What is the read-your-writes consistency problem with replicas and how do you solve it? — A write to master may not yet be visible on a replica the client reads next. Solutions: sticky reads to master after writes, track replication position and wait, or use synchronous replication.
• How does Galera Cluster guarantee no write conflicts while allowing multi-master writes? — Galera uses a certification-based protocol: each transaction's write set is broadcast; nodes certify no conflicting transaction was committed first. Conflicts cause one transaction to abort at commit time.
• What is semi-synchronous replication and what consistency guarantee does it provide? — At least one replica acknowledges the write before the master commits. Guarantees no data loss for the acknowledged write on replica failure, but does not prevent data loss if the master fails before any replica acknowledges.

Related Questions

• ACID
• Indexes
• Clustered vs Non-clustered
• Isolation Levels
• Normalization