How Leader–Follower Replication Works

Prerequisites(1)

Builds on to(5)

Replication Lag Multi-Leader Replication Leaderless Replication (Dynamo)Consistent Hashing Change Data Capture (CDC)

Leader–follower replication (also called primary–replica or master–slave replication) is the most common replication strategy in databases. A single node, the leader, accepts all write operations. Every time the leader writes new data to its local storage, it also sends the change to all follower nodes via a replication log. Followers apply these changes in the same order, maintaining an identical copy of the data.

Write and Read Flow

All writes must go through the leader, which serializes them into a deterministic order. Followers can serve read queries, distributing read load across multiple machines. This is particularly effective for read-heavy workloads where the read-to-write ratio is 10:1 or higher.

Synchronous vs Asynchronous Replication

Synchronous: The leader waits for a follower to confirm it has written the data before reporting success to the client. Guarantees the follower has an up-to-date copy, but any follower failure blocks writes.
Asynchronous: The leader sends changes but does not wait for confirmation. Writes are fast, but if the leader crashes, any unreplicated writes are lost.
Semi-synchronous: The leader waits for at least one follower to confirm (the synchronous follower), while others replicate asynchronously. This balances durability with availability. PostgreSQL and MySQL both support this mode.

Replication Methods

Statement-based: The leader logs every SQL statement (INSERT, UPDATE, DELETE) and sends it to followers. Simple, but non-deterministic functions like NOW() or RAND() produce different results on different nodes.
WAL (Write-Ahead Log) shipping: The leader sends its physical WAL to followers, who replay the exact byte-level changes. Tightly coupled to storage engine internals, making version upgrades difficult.
Logical (row-based) replication: The leader sends a structured description of row changes (which row was inserted/updated/deleted, with the new column values). Decoupled from storage format, enabling cross-version and even cross-engine replication. PostgreSQL logical replication and MySQL binlog in ROW format use this approach.

Failover

When the leader becomes unavailable, a follower must be promoted to the new leader. This process, called failover, involves: (1) detecting the leader has failed (usually via a timeout), (2) choosing a new leader (the follower with the most up-to-date data), and (3) reconfiguring clients and other followers to use the new leader. Failover is risky: if two nodes both believe they are leader, split-brain occurs, potentially causing conflicting writes and data corruption.

Real-Life: PostgreSQL Streaming Replication

Real-World Example

PostgreSQL uses leader–follower replication extensively in production deployments:

A primary server handles all writes. One or more standby servers continuously stream WAL records from the primary and replay them.
Synchronous standby: PostgreSQL can be configured so the primary waits for at least one standby to confirm a write (synchronous_commit = on). If the synchronous standby fails, another standby is automatically promoted to synchronous.
pg_basebackup: a tool to create a new follower by taking a consistent snapshot of the leader and then streaming the WAL from the snapshot point forward.
Patroni and pg_auto_failover: orchestration tools that automate failover, monitoring the leader via heartbeats, promoting the most up-to-date follower, and updating the connection endpoint.

MySQL follows a similar model with its binlog replication, where the primary writes changes to the binary log and replicas pull and replay them. Group Replication extends this to support multi-primary setups with automatic conflict detection.

**Leader–follower replication** (also called primary–replica or master–slave replication) is the most common replication strategy in databases. A single node, the **leader**, accepts all write operations. Every time the leader writes new data to its local storage, it also sends the change to all **follower** nodes via a **replication log**. Followers apply these changes in the same order, maintaining an identical copy of the data.

### Write and Read Flow

All writes must go through the leader, which serializes them into a deterministic order. Followers can serve **read queries**, distributing read load across multiple machines. This is particularly effective for read-heavy workloads where the read-to-write ratio is 10:1 or higher.

### Synchronous vs Asynchronous Replication

- **Synchronous**: The leader waits for a follower to confirm it has written the data before reporting success to the client. Guarantees the follower has an up-to-date copy, but any follower failure blocks writes.
- **Asynchronous**: The leader sends changes but does not wait for confirmation. Writes are fast, but if the leader crashes, any unreplicated writes are lost.
- **Semi-synchronous**: The leader waits for **at least one** follower to confirm (the synchronous follower), while others replicate asynchronously. This balances durability with availability. PostgreSQL and MySQL both support this mode.

### Replication Methods

1. **Statement-based**: The leader logs every SQL statement (INSERT, UPDATE, DELETE) and sends it to followers. Simple, but non-deterministic functions like `NOW()` or `RAND()` produce different results on different nodes.
2. **WAL (Write-Ahead Log) shipping**: The leader sends its physical WAL to followers, who replay the exact byte-level changes. Tightly coupled to storage engine internals, making version upgrades difficult.
3. **Logical (row-based) replication**: The leader sends a structured description of row changes (which row was inserted/updated/deleted, with the new column values). Decoupled from storage format, enabling cross-version and even cross-engine replication. PostgreSQL logical replication and MySQL binlog in ROW format use this approach.

### Failover

When the leader becomes unavailable, a follower must be **promoted** to the new leader. This process, called **failover**, involves: (1) detecting the leader has failed (usually via a timeout), (2) choosing a new leader (the follower with the most up-to-date data), and (3) reconfiguring clients and other followers to use the new leader. Failover is risky: if two nodes both believe they are leader, **split-brain** occurs, potentially causing conflicting writes and data corruption.

**PostgreSQL** uses leader–follower replication extensively in production deployments:

- A primary server handles all writes. One or more **standby** servers continuously stream WAL records from the primary and replay them.
- **Synchronous standby**: PostgreSQL can be configured so the primary waits for at least one standby to confirm a write (`synchronous_commit = on`). If the synchronous standby fails, another standby is automatically promoted to synchronous.
- **pg_basebackup**: a tool to create a new follower by taking a consistent snapshot of the leader and then streaming the WAL from the snapshot point forward.
- **Patroni** and **pg_auto_failover**: orchestration tools that automate failover, monitoring the leader via heartbeats, promoting the most up-to-date follower, and updating the connection endpoint.

**MySQL** follows a similar model with its **binlog replication**, where the primary writes changes to the binary log and replicas pull and replay them. Group Replication extends this to support multi-primary setups with automatic conflict detection.

Leader–Follower Replication Flow

Step 1 of 2