Replication: Full Sync

Replication gives Redis a way to copy a primary's dataset to one or more replicas and then keep those replicas moving forward as writes happen.

The simplest version of the story is:

replica connects -> primary sends current dataset -> primary streams future writes

That is full synchronization. It is the foundation underneath replica creation, failover readiness, read scaling, and some persistence workflows.

Primary And Replica Roles

A primary accepts writes from clients and propagates those writes to replicas. A replica receives the primary's dataset and applies the primary's write stream.

Redis replication is asynchronous by default. A primary can reply to a client before every replica has applied the write. That improves latency but creates a possible data-loss window if the primary fails before replicas catch up.

This is the central replication tradeoff:

lower write latency <-> stronger certainty that replicas have the write

The Full Sync Sequence

A simplified full sync looks like this:

replica connects to primary
replica sends handshake information
replica asks to synchronize
primary replies with full resync identity
primary creates a snapshot of the dataset
primary sends snapshot bytes
primary sends writes that happened during snapshot creation
primary continues streaming new writes

In Redis protocol terms, the synchronization conversation includes commands such as PING, capability negotiation, and PSYNC. The important shape is the split between a bulk dataset transfer and an ongoing command stream.

Why The Snapshot Is Not Enough

Suppose the primary starts creating a snapshot at time t0.

While the snapshot is being produced, clients continue writing:

t0: snapshot begins
t1: SET a 1
t2: DEL b
t3: snapshot finishes

The snapshot represents the dataset at t0. If the replica only loads that snapshot, it misses the writes at t1 and t2.

So the primary buffers writes that happen during snapshot creation and sends them after the snapshot. Once the replica has loaded the snapshot and applied the buffered writes, it can continue applying the live replication stream.

The full sync is therefore two operations stitched together:

copy a point-in-time state
then apply every change after that point

Replicas Apply, They Do Not Decide

During replication, a replica applies writes from the primary. In the ordinary model, it should not independently accept conflicting writes. If it did, the primary and replica would become different databases.

Internally, replicated commands travel through an apply path that resembles command execution but has different context. The replica must update its dataset and replication offset, but it should not treat those writes as local client decisions.

Full Sync Is Expensive But Universal

Full synchronization works even when a replica has no useful prior state. That makes it robust. It is also expensive: it can require creating a snapshot, transferring a large file, loading that file, and buffering writes during the transfer.

That cost is why Redis also supports partial synchronization. If a replica only missed a small suffix of the primary's write stream, sending the whole dataset again would be wasteful.

Full sync is the reset button. It says: discard assumptions, copy the state, then follow the stream.