Redis Replication Basics

Redis replication lets one Redis server, the master (also called the primary), automatically copy its entire dataset to one or more replicas (formerly called slaves). Replicas stay in sync with the master by receiving a continuous stream of the write commands the master processes, so they hold a near-real-time copy of the data. Replication is the foundation for read scaling, high availability, and disaster recovery in Redis — it’s what makes automatic failover with Sentinel or Redis Cluster possible.

Overview: How Redis Replication Works

Redis replication is asynchronous by default: the master does not wait for a replica to acknowledge a write before responding to the client. This keeps the master fast, but it means a replica can lag behind the master by a small amount — usually milliseconds on a healthy network, but potentially much more if a replica is slow, disconnected, or overloaded. Because a single Redis instance is single-threaded, every write command executes atomically and in a strict order on the master; replicas apply that exact same sequence of commands in the exact same order, which is what keeps them consistent with the master over time (eventual consistency, not synchronous consistency).

Replication is set up with a leader-follower topology: one master can have many replicas, and (as of Redis 4.0+) replicas can themselves have sub-replicas, forming a chain that reduces load on the master when you need many copies of the data. Every replica is, by default, read-only — clients can run read commands against it but writes are rejected, which is exactly what lets you scale reads horizontally by pointing read traffic at replicas while all writes go to the master.

Each master maintains a replication ID and a replication offset (a running byte count of the write stream). When a replica connects, Redis performs either a full resynchronization (the master takes an RDB snapshot, sends it to the replica, and then streams any writes that happened since) or, if the replica was previously connected and only briefly disconnected, a partial resynchronization using a backlog buffer of recent writes — this avoids re-transferring the whole dataset for a short network blip. You can also configure diskless replication, where the master streams the RDB payload directly over the socket instead of writing it to disk first, which is often faster on modern hardware.

It’s important to understand that replication alone is not a backup strategy: a mistaken DEL or a bad write on the master replicates to every replica just as faithfully as a good one. Replication protects you against hardware failure and lets you scale reads and perform failover — it does not protect you against application bugs or accidental data loss. For that you still need RDB/AOF persistence and, ideally, offsite snapshots.

Syntax

The core commands used to inspect and control replication are:

Command Description Time complexity
REPLICAOF host port Makes the current instance a replica of the server at host:port. O(1)
REPLICAOF NO ONE Promotes a replica back to a standalone master (stops replicating). O(1)
ROLE Reports whether the current instance is master or slave, plus offset and connected-replica info. O(1)
INFO replication Returns a detailed text report of replication state (role, connected replicas, offsets, replication ID). O(1)
WAIT numreplicas timeout Blocks the client until at least numreplicas replicas have acknowledged all writes issued so far, or until timeout milliseconds elapse (0 = wait forever). O(1)

REPLICAOF is the modern name for the older SLAVEOF command; both still work, but new code and documentation use REPLICAOF. Replica configuration (such as which master to follow on startup) is normally set once in redis.conf rather than issued interactively every time the server starts.

Examples

Example 1: Checking the role of a fresh instance. A brand-new Redis server with no replication configured is its own master with no replicas attached:

ROLE

Output:

1) "master"
2) (integer) 0
3) (empty array)

The first element is the role, the second is the current replication offset (0 because nothing has been written yet), and the third is the list of connected replicas — empty here because none are attached.

Example 2: Reading the full replication report with INFO replication.

INFO replication

Output:

# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:8c3b1f1e2a9d4c7e8f0a1b2c3d4e5f6a7b8c9d0e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

master_replid is a random hex string generated when the server starts (yours will differ) — replicas record this ID so Redis can tell whether a reconnecting replica is resuming the same replication history (allowing a fast partial resync) or needs a fresh full sync. connected_slaves and master_repl_offset are the two fields you watch most in production to confirm replicas exist and are catching up.

Example 3: Using WAIT after a write for stronger durability guarantees.

SET order:1001:status "paid"
WAIT 0 100

Output:

OK
(integer) 0

WAIT 0 100 asks Redis to block until 0 replicas have acknowledged the write, with a 100ms timeout — since the requirement is already satisfied (0 replicas needed), it returns immediately with the number of replicas that acknowledged. In a real master-replica deployment you’d call something like WAIT 1 100 after a critical write to confirm at least one replica has the data before telling your own caller the write is durable — this trades a little latency for a much stronger guarantee than Redis’s default fire-and-forget asynchronous replication.

Example 4: Attaching a replica (illustrative). On a second Redis server, you point it at the master with REPLICAOF:

REPLICAOF 203.0.113.10 6379
INFO replication
REPLICAOF NO ONE

Illustrative output (on the replica, right after connecting):

OK
# Replication
role:slave
master_host:203.0.113.10
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_read_repl_offset:196
slave_repl_offset:196
slave_priority:100
slave_read_only:1
replica_announced:1
OK

This isn’t run against the lesson’s test server (there’s no second Redis instance to point it at here), but it shows exactly what you’d type and see on real hardware or containers. master_link_status:up confirms the replica successfully completed its handshake and sync; the final REPLICAOF NO ONE detaches it and promotes it back to a standalone master.

How It Works Step by Step

When a replica connects to a master (via REPLICAOF host port or a replicaof line in its config file), the following happens:

  1. The replica opens a TCP connection to the master and performs a handshake, exchanging PING and configuration details.
  2. The replica sends PSYNC replicationid offset, asking to resume from a known point.
  3. If the master recognizes that replication ID and still has the requested offset in its backlog buffer, it performs a partial resync: it sends only the missing commands. This is fast and cheap.
  4. Otherwise the master performs a full resync: it forks (or streams diskless), generates an RDB snapshot of the entire dataset, and transfers it to the replica while buffering any writes that occur during the transfer in its replication backlog.
  5. The replica loads the RDB snapshot, flushing its own prior dataset, then applies the buffered write stream to catch up to the master’s current state.
  6. From then on, the master forwards every write command to all connected replicas as it executes them — the same single-threaded command order on the master is preserved on every replica, which is why replicas stay logically consistent with the master (modulo the small propagation delay).
  7. Replicas periodically send back their replication offset as an acknowledgment, which is what commands like WAIT and fields like slave_repl_offset rely on to measure replication lag.

Common Mistakes

Mistake 1: Assuming replication is synchronous. A write that returns OK on the master has not necessarily reached any replica yet. If the master crashes immediately after, that write can be lost even though the client already got a success reply. If you need a stronger guarantee, use WAIT numreplicas timeout after critical writes instead of assuming the replica already has the data.

Mistake 2: Writing directly to a replica. Replicas reject writes by default:

SET session:abc123 "active"

Output on a read-only replica:

(error) READONLY You can't write against a read only replica.

All writes must go to the master. Application code that fans reads out to replicas needs a separate connection (or a client that understands the topology) for writes — pointing your write path at a replica by mistake will fail every write.

Mistake 3: Treating replication as a backup. Because every write — including an accidental DEL or a buggy script that corrupts data — replicates to every replica, having replicas does not protect you from data loss caused by your own application. You still need RDB snapshots, AOF, and ideally an offsite/point-in-time backup strategy separate from live replicas.

Mistake 4: Never checking replica lag. A replica that has fallen far behind (e.g., due to network issues or a slow disk) can serve badly stale reads without any obvious error. Regularly checking connected_slaves, master_repl_offset versus the replica’s own offset, and master_link_status in INFO replication is the only way to catch this before it causes a user-visible problem.

Best Practices

  • Use replicas to scale read throughput, not to add write capacity — all writes must still go through the single master.
  • Monitor master_repl_offset on the master versus slave_repl_offset on each replica to detect replication lag before it affects reads.
  • Use WAIT selectively for writes where losing data on master failure is unacceptable; don’t call it after every write, since it adds latency.
  • Never rely on replication alone as your backup strategy — keep RDB/AOF persistence and off-server backups in place.
  • For automatic failover (promoting a replica to master when the master dies), use Redis Sentinel or Redis Cluster rather than manually running REPLICAOF NO ONE during an incident.
  • Keep replicas on reasonably fast, reliable network links to the master — replication lag is fundamentally a function of network and disk throughput between master and replica.
  • Remember replicas are read-only by default; design your client/connection layer to route writes to the master and reads to replicas explicitly.

Practice Exercises

Exercise 1: On a single running Redis instance, run ROLE and then INFO replication. Identify which fields would change if you attached a replica, without actually attaching one.

Exercise 2: Write three keys with SET, then run WAIT 0 100 after the last one. Explain in your own words why the command returns immediately with (integer) 0 even though there are no replicas connected.

Exercise 3 (thought exercise): Imagine a master and one replica, where the replica has been disconnected from the network for 30 seconds and then reconnects. Based on the step-by-step process above, describe whether Redis will attempt a partial or full resync, and what determines the answer.

Summary

  • Redis replication copies a master’s dataset to one or more replicas asynchronously, using a full resync (RDB snapshot + backlog) or a faster partial resync when possible.
  • Because Redis is single-threaded, the master’s exact write order is preserved when replicas apply that same stream, keeping them eventually consistent.
  • Replicas are read-only by default and reject writes with a READONLY error — all writes must target the master.
  • ROLE and INFO replication are the primary tools for inspecting replication state; REPLICAOF/REPLICAOF NO ONE attach or detach a replica.
  • WAIT numreplicas timeout lets you trade latency for a stronger durability guarantee on critical writes.
  • Replication is not a backup: it faithfully copies mistakes as well as good writes, so persistence and real backups are still required.
  • For automatic failover, use Sentinel or Redis Cluster rather than manual replica promotion.