Replication

Introduction

A single Redis server can handle enormous throughput, but it remains a single point of failure. Replication creates one or more copies (replicas) of your data on separate machines. If the primary (master) fails, a replica can take over. This chapter covers how Redis replication works, how to configure it, and the operational details you need to keep a replicated setup healthy.

Prerequisites

• A running Redis server and comfort with redis-cli
• Understanding of persistence basics (see Persistence)
• Two or more Redis instances (or separate ports on one machine for testing)

The Master-Replica Model

Redis replication is asynchronous by default. The master accepts writes and streams them to replicas, which apply the changes to their own datasets. Replicas can accept reads (if configured), but they reject writes by default to prevent divergence.

         ┌─────────────┐
         │   Master    │ ← writes
         │   :6379     │
         └──────┬──────┘
                │ replication stream
       ┌────────┴────────┐
       ↓                 ↓
┌─────────────┐   ┌─────────────┐
│  Replica 1  │   │  Replica 2  │ ← reads (optional)
│   :6380     │   │   :6381     │
└─────────────┘   └─────────────┘

Configuring a Replica

There are two ways to attach a replica to a master.

Via configuration file:

# redis-replica.conf
replicaof 127.0.0.1 6379

Via command at runtime:

# On the replica instance
redis-cli -p 6380
REPLICAOF 127.0.0.1 6379

To promote a replica back to an independent master:

redis-cli -p 6380
REPLICAOF NO ONE

Verifying Replication Status

On the master:

redis-cli INFO replication

Look for:

role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=12345,lag=0

On the replica:

role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1

master_link_status:down means the replica has lost its connection and is attempting to reconnect.

How Replication Starts

When a replica connects to a master for the first time, or after a long disconnection, it goes through one of two synchronization paths.

Full Synchronization

1. The master forks a child process to generate an RDB snapshot.
2. The master buffers all new write commands in a replication backlog.
3. The child sends the RDB file to the replica.
4. The replica loads the RDB file into memory.
5. The master sends the buffered backlog commands to the replica.
6. Normal streaming resumes: every new write is forwarded live.

Full sync is expensive. It blocks the master briefly for the fork, consumes network bandwidth for the file transfer, and forces the replica to flush its current data.

Partial Synchronization

Redis 2.8 introduced PSYNC, which avoids the full RDB transfer when possible. The master maintains a circular replication backlog (a buffer of recent commands). If a replica reconnects quickly enough that its last received offset still exists in the backlog, the master simply replays the missing commands.

# Size of the replication backlog (default 1mb)
repl-backlog-size 64mb
 
# How long to keep the backlog after the last replica disconnects
repl-backlog-ttl 3600

A larger backlog increases the chance that a brief network hiccup can be healed with partial sync instead of a costly full sync.

Read-Only Replicas and Read Scaling

By default, replicas reject write commands. You can allow reads from replicas to distribute query load:

# On the replica
replica-read-only yes

This is the default and recommended setting. A read-only replica cannot accidentally diverge from the master.

Diskless Replication

By default, the master writes the RDB snapshot to disk before sending it to the replica. Redis 2.8.18 added diskless replication, where the child process writes the RDB directly to the replica's socket without touching the filesystem.

# On the master: do not write RDB to disk during replication
repl-diskless-sync yes
 
# Delay the first replica so others can attach and share the same sync
repl-diskless-sync-delay 5

Diskless replication is useful when disk I/O is a bottleneck or when the master runs in an environment with slow or ephemeral disks.

Securing Replication

If your master requires authentication, the replica must provide the password:

# On the replica
masterauth your-strong-password

For Redis 6 and later, you can use ACLs to grant the replica a restricted set of permissions:

# On the master
ACL SETUSER replica_user on >replica_pass allkeys +psync +replconf +ping

Then configure the replica with:

masteruser replica_user
masterauth replica_pass

Monitoring Replication Health

A healthy replica should show master_last_io_seconds_ago under 10 seconds in a production environment. Values above 30 seconds suggest network trouble or the master is too busy to stream commands.

FAQ

Can I have a replica of a replica?

Yes. Redis supports cascading replication: A → B → C. C replicates from B, which replicates from A. This reduces master load in large topologies but adds replication lag at each hop.

What happens if the master crashes?

Replication alone does not promote a replica to master automatically. You need Redis Sentinel or Redis Cluster for automatic failover. Without them, you must manually run REPLICAOF NO ONE on a chosen replica and redirect clients.

Does replication impact master performance?

Usually minimal. The master forks for full syncs (a brief CPU and memory spike) and otherwise writes to replica sockets asynchronously. A very large number of replicas or slow network links can consume outbound bandwidth and CPU for protocol encoding.

Can replicas have different persistence settings than the master?

Yes. A common pattern is to disable RDB and AOF on the master for maximum write throughput, while enabling persistence on one or more replicas. If the master fails, you still have durable copies.

Why is my replica stuck in master_sync_in_progress:1?

The replica is receiving a full RDB file. Check master_sync_left_bytes to see progress. If it stays stuck, verify network connectivity, disk space on the replica, and that the master can fork successfully.