Redis Replication
How asynchronous replication works, what WAIT does and does not guarantee, and the buffers that decide whether a reconnect is cheap.
A Redis replica maintains a copy of a primary's dataset and serves reads. Replication is asynchronous: the primary acknowledges a write to the client before the replica has it.
# On the replica.
replicaof 10.20.1.10 6379
masterauth <password>
replica-read-only yesFull and partial resynchronisation
On first connection the replica performs a full sync: the primary forks, produces an RDB snapshot, sends it, and streams the writes that happened meanwhile.
On a brief disconnect the replica attempts a partial resync using the replication backlog — a ring buffer of recent writes on the primary.
repl-backlog-size 64mb
repl-backlog-ttl 3600Diskless replication
repl-diskless-sync yes
repl-diskless-sync-delay 5
repl-diskless-load swapdbDiskless sync streams the RDB directly to the replica socket instead of writing it to disk first.
This helps when disks are slow or space is tight; it means the primary cannot serve the same
snapshot to several replicas that connect at different moments, which is what
repl-diskless-sync-delay batches for.
Consistency
WAIT numreplicas timeout blocks until the given number of replicas have acknowledged all writes
issued by this connection:
SET order:4711:status paid
WAIT 1 100It narrows the window and does not close it: WAIT confirms receipt, not durability on disk, and
it is not a consensus protocol. Treat it as a risk reduction, not a guarantee.
Preventing stale reads
Replicas serve stale data by definition. Two controls:
# On the replica: stop serving reads if it has been disconnected too long.
replica-serve-stale-data no
# On the primary: refuse writes unless N replicas are connected and lagging < M seconds.
min-replicas-to-write 1
min-replicas-max-lag 10min-replicas-to-write makes the primary fail writes rather than accept data it cannot replicate.
That converts a silent durability loss into a visible error — usually the right trade for data you
care about, and the wrong one for a pure cache.
Monitoring
INFO replicationKey fields: role, connected_slaves, master_link_status (must be up on a replica),
master_repl_offset versus each replica's offset for lag in bytes, and sync_full /
sync_partial_err in INFO stats to spot repeated full resynchronisations.