What Redis Replication Does
Redis replication lets one primary instance stream a continuous copy of its dataset to one or more replica instances. A replica connects to the primary, performs an initial synchronization, and then applies every subsequent write the primary receives, in the same order. This gives you read scaling (replicas can serve GET-style traffic) and a warm standby that can be promoted if the primary fails. Replication in Redis is asynchronous by default: the primary does not wait for a replica to acknowledge a write before replying to the client.
Cricket analogy: Think of the primary as the stadium's official scoreboard operator and replicas as the scrolling tickers outside the ground; when Kohli hits a six, the ticker updates a beat later, not instantly, because the update has to travel.
Full Sync vs Partial Resynchronization
When a replica first connects, or when its replication link has been broken for too long, Redis performs a full synchronization: the primary forks a background save (RDB snapshot), transfers that snapshot to the replica, and then streams the backlog of commands issued during the transfer. This is expensive on a large dataset. To avoid repeating this work after brief network blips, Redis maintains a replication backlog — a bounded in-memory buffer of recent write commands keyed by a replication ID and offset. If a replica reconnects within the backlog's window, it performs a partial resynchronization (PSYNC), receiving only the missed commands instead of a fresh RDB transfer.
Cricket analogy: It's the difference between re-watching an entire Test match highlights reel from ball one after missing the whole day, versus catching just the last 20 minutes of play you missed during a rain delay.
Configuring a Replica
# On the replica instance (redis.conf or CONFIG SET)
replicaof 10.0.0.5 6379
# Or dynamically via redis-cli against the replica:
redis-cli -h 10.0.0.10 REPLICAOF 10.0.0.5 6379
# Check replication status on the primary:
redis-cli -h 10.0.0.5 INFO replication
# connected_slaves:1
# slave0:ip=10.0.0.10,port=6379,state=online,offset=445210,lag=0
# Promote a replica to primary (manual failover):
redis-cli -h 10.0.0.10 REPLICAOF NO ONEConsistency and Failure Behavior
Because replication is asynchronous, a client that writes to the primary and immediately reads from a replica can see stale data — the write may not have arrived yet. Redis exposes WAIT to let a client block until a write has been acknowledged by a minimum number of replicas, trading latency for durability confidence, though it does not make replication synchronous by default. If the primary crashes before a write reaches any replica, that write is lost even though the client received an OK. This is the core tradeoff: replication protects against instance loss, not against every possible write loss window.
Cricket analogy: It's like a run being credited on the field but the stadium's official scorecard app updating a second later — someone refreshing the app mid-run might briefly see the old score.
Never treat a replica as a durability guarantee by itself. If the primary dies mid-write and no replica had received that command, the write is gone even though the original client got an OK reply. Combine replication with AOF persistence and WAIT (or Sentinel/Cluster quorum) if you need stronger loss guarantees.
Replicas are read-only by default (replica-read-only yes). This prevents accidental divergence between primary and replica datasets, since any writes accepted directly on a replica would not propagate back upstream.
- Replication is asynchronous by default; the primary does not wait for replica acknowledgment before responding to clients.
- New or long-disconnected replicas trigger a full sync (RDB transfer + backlog replay); brief disconnects allow partial resync (PSYNC) using the replication backlog.
- Replicas are read-only by default to prevent divergence from the primary.
- WAIT lets clients require acknowledgment from N replicas before proceeding, improving durability confidence without making replication fully synchronous.
- Read-after-write on a replica can return stale data due to propagation lag.
- A primary crash can silently lose writes that never reached any replica — replication is not a substitute for persistence.
- INFO replication on the primary reports connected replicas, their offsets, and lag, which is essential for monitoring replication health.
Practice what you learned
1. By default, how does a Redis primary handle acknowledgment from replicas when processing a write?
2. What triggers a full synchronization instead of a partial resynchronization (PSYNC)?
3. What is the default write behavior of a Redis replica?
4. What risk does asynchronous replication introduce?
5. What does the WAIT command allow a client to do?
Was this page helpful?
You May Also Like
Redis Sentinel for High Availability
How Redis Sentinel monitors a primary/replica deployment, detects failures, and orchestrates automatic failover without a cluster topology.
Redis Cluster Explained
How Redis Cluster shards data across multiple nodes using hash slots, and how it handles failover and multi-key operations.
Redis Persistence Tradeoffs
A practical comparison of RDB snapshots and AOF logging in Redis, and how to choose or combine them based on your durability and performance needs.