Set up a Redis replica

Picture this: your production Redis instance goes down, and every request that depended on it instantly fails. Your cache is empty, sessions are lost, and your application grinds to a halt. This is the exact pain a Redis replica solves. By creating a read-only copy of your primary Redis server, you gain data redundancy, read scaling, and a safety net for high availability. This lesson walks you through setting up a Redis replica step by step, from configuration to verification, so you can protect your data and improve performance — all without downtime.

The problem this lesson solves

A single Redis instance is a single point of failure. If it crashes or becomes unreachable, your application loses its cache, session store, or queue. Even if the server restarts, any in-memory data not persisted is gone forever. Scaling read operations is also hard with one server: every client competes for the same CPU and memory, creating bottlenecks.

Replication addresses both issues. A Redis replica is a separate Redis server that maintains an identical copy of the data from the primary (also called master). The primary handles writes, while replicas serve read requests. If the primary fails, you can promote a replica to take over — a core pattern for Redis Sentinel or Redis Cluster.

Core concept / mental model

Think of Redis replication as a primary-server pattern with one-way data flow. The primary server is the authoritative source of truth. Every time a write happens on the primary (SET, HSET, LPUSH, etc.), the command is forwarded asynchronously to all connected replicas. The replicas apply those same commands in order, maintaining an exact copy of the dataset.

Key characteristics: - Asynchronous by default: the primary does not wait for replicas to confirm before returning success. This makes replication fast but allows for a small window of data loss on failover. - Replica is read-only by default: you cannot write directly to a replica. This ensures consistency. - Partial resynchronization: if a replica disconnects briefly, Redis can catch up using a backlog buffer instead of a full resync. - Replication ID and offset: each primary produces a stream of data identified by a unique replication ID and an offset. Replicas track where they are in the stream.

Pro tip: Replication is a foundation for Redis Sentinel (automatic failover) and Redis Cluster (sharding + replication). Mastering this single step unlocks production-grade Redis architectures.

How it works step by step

Setting up a Redis replica follows a straightforward process. You configure a second Redis server to connect to the primary. Here’s what happens behind the scenes when a replica connects for the first time:

1. Configuration: On the replica, you set replicaof <primary-ip> <primary-port> (or the legacy slaveof) in redis.conf, or use the REPLICAOF command at runtime.
2. Handshake: The replica sends a PING to the primary, then authenticates if masterauth is set. It then identifies as a replica and requests the primary’s replication ID and offset.
3. Full resynchronization: If the replica is empty or the offset is no longer in the primary’s backlog, the primary forks a child process to BGSAVE an RDB snapshot. The primary streams this snapshot to the replica.
4. Load phase: The replica receives the RDB file, deletes its own data, and loads the snapshot. During this time, the replica is not yet serving read requests.
5. Replication stream: After loading, the replica starts receiving buffered write commands from the primary. From that point, it stays connected and applies every write command in real time.
6. Continuous sync: The primary holds a replication backlog (a circular buffer of recent commands). If a replica disconnects and reconnects quickly, it can resume from the backlog without a full resync.

Hands-on walkthrough

Let’s set up a Redis replica using two local Redis instances. We’ll run the primary on port 6379 and the replica on port 6380. Make sure you have Redis installed (version 6+ recommended).

1. Start the primary

Create a minimal config for the primary (or use defaults). Start it:

redis-server --port 6379 &

Verify it's running:

redis-cli -p 6379 PING
# PONG

2. Configure the replica

Create a configuration file for the replica (e.g., replica.conf):

# replica.conf
port 6380
replicaof 127.0.0.1 6379
# Enable log to see sync progress
loglevel notice
logfile /tmp/replica.log

Alternatively, you can pass these as command-line arguments:

redis-server --port 6380 --replicaof 127.0.0.1 6379

3. Start the replica and observe sync

Start the replica with your config:

redis-server /path/to/replica.conf

Check its log (or use redis-cli):

redis-cli -p 6380 INFO replication

Expected output (partial):

# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
slave_read_repl_offset:14
slave_repl_offset:14
...

4. Verify data replication

Write some data to the primary:

redis-cli -p 6379 SET user:1001 "Alice"

Read from the replica:

redis-cli -p 6380 GET user:1001
# "Alice"

The replica immediately reflects the write. Try writing to the replica directly:

redis-cli -p 6380 SET user:1002 "Bob"
# (error) READONLY You can't write against a read-only replica.

This confirms the replica is enforcing read-only mode.

5. Test partial resync

Simulate a brief network interruption:

redis-cli -p 6380 DEBUG SLEEP 5
# Wait a few seconds, then check
redis-cli -p 6380 INFO replication | grep master_link_status
# master_link_status:down

After the replica reconnects:

redis-cli -p 6380 INFO replication | grep master_link_status
# master_link_status:up

If the backlog still contains the missed commands, the replica will do a partial resync (no full RDB transfer).

Compare options / when to choose what

When to choose what: - Single instance: Development, testing, or ephemeral data where loss is acceptable. - One replica: Production systems that need a backup for failover, plus some read offloading. - Multiple replicas: High-read traffic, geo-distribution, or when you need redundancy across data centers.

For most production scenarios, start with one replica on a separate server. Use Redis Sentinel to automate failover between primary and replica.

Troubleshooting & edge cases

Replica not syncing

• Firewall: Ensure the replica can reach the primary’s port (default 6379).
• Authentication: If the primary has requirepass, set masterauth <password> in the replica config.
• Disk space: Full resync creates an RDB file. Ensure enough free disk on the replica.
• Timeout: Increase repl-timeout (default 60s) if the network is slow.

Replica lagging behind

Check master_last_io_seconds_ago in the replica’s INFO replication output. If it grows, the primary might be overloaded. Tune: - client-output-buffer-limit replica to allow larger buffers. - repl-backlog-size to hold more commands during brief disconnects.

Replica promoting to primary

To promote a replica manually, run:

redis-cli -p 6380 REPLICAOF NO ONE

This makes the replica a standalone primary. Data is preserved.

Edge case: If the old primary goes down and the replica is promoted, restarting the old primary later will cause a split-brain. Always configure Redis Sentinel or manually replicate the new primary.

Memory limitations

Replicas maintain a copy of the entire dataset. If your dataset is 10 GB, each replica also needs 10 GB RAM. Plan accordingly.

What you learned & what's next

You now know how to set up a Redis replica: configure replicaof, start a second instance, verify replication, and understand the synchronization protocol. You’ve seen how replicas provide data redundancy and read scaling, and you’ve learned key troubleshooting: authentication, firewalls, and promoting a replica.

Your next step is to automate failover using Redis Sentinel. With Sentinel, you’ll configure automated monitoring, notification, and promotion of a replica when the primary fails. This completes the high availability picture. Head to the next lesson: "Set up Redis Sentinel for automatic failover."