Scaling Redis with Replication: A Hands-On Guide

Previously in this course, we covered Understanding Redis Persistence to ensure data durability. In this lesson, we move from protecting data against crashes to ensuring your service stays available during hardware failures and scales to meet increasing read demand through replication.

Scaling Redis with Replication: The Fundamentals

In a standard Redis deployment, a single node handles all operations. If that node goes down, your cache—and potentially your application performance—goes with it. By using a master-replica architecture, you designate one node as the master (which handles all writes) and one or more replicas to mirror that data.

Replication in Redis is asynchronous. When the master receives a write command, it executes it locally and then streams the command to its replicas. This allows you to offload read-heavy workloads to your replicas, effectively scaling your read throughput.

Configuring a Redis Replica

Configuring a replica is straightforward. You don't need to change the master's configuration; you only need to tell the new instance which master to follow.

1. Start the Master

Assuming you have your Redis server running on 127.0.0.1:6379.

2. Start the Replica

Start a second Redis instance on a different port (e.g., 6380):

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

The --replicaof flag instructs this new process to immediately connect to the master at 127.0.0.1:6379 and begin a full data synchronization.

Verifying Replication Status

Once the processes are running, verify the connection using redis-cli. Connect to your replica (port 6380) and run the INFO replication command:

Bash
redis-cli -p 6380
127.0.0.1:6380> INFO replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
...

If master_link_status is up, the replica is correctly synchronized. Now, try setting a key in the master (6379) and reading it from the replica (6380):

Bash
# On Master
redis-cli -p 6379 SET user:101 "Alice"

# On Replica
redis-cli -p 6380 GET user:101
"Alice"

Understanding Failover and Availability

Replication alone does not make your system "highly available" in the sense of automatic recovery. If your master dies, your replica remains a read-only slave; it will not automatically promote itself to master.

To achieve true high availability, we use Redis Sentinel. Sentinel is a distributed system that monitors your master and replicas. If it detects a master failure, it performs an automatic failover:

1. It elects one of the replicas to become the new master.
2. It reconfigures the remaining replicas to point to the new master.
3. It notifies your application of the new master's address.

For a deeper dive into the architectural trade-offs between different replication models, you can refer to Database Replication Strategies: Synchronous vs Asynchronous Explained.

Hands-On Exercise

1. Setup: Launch two Redis instances on your local machine using different ports as shown above.
2. Sync: Verify the master-replica connection using INFO replication.
3. Test: Write data to the master and confirm its presence on the replica.
4. Kill: Terminate the master process (Ctrl+C). Observe what happens to the replica's master_link_status in the INFO output. Note that the replica is now "stuck" because it cannot reach the master.

Common Pitfalls

• Blocking Reads: By default, replicas are read-only. If you accidentally write to a replica, you will get an error.
• Replication Lag: Because replication is asynchronous, a read from a replica might return "stale" data if the master hasn't finished propagating the change. Always account for slight latency in your application logic.
• Manual Failover: Never promote a replica to master manually in production without stopping the old master, or you risk a "split-brain" scenario where two nodes think they are the primary source of truth.

FAQ

Does replication replace backups? No. Replication is for high availability and read scaling. If you execute a FLUSHALL command on your master, that deletion is replicated to all slaves. You still need RDB or AOF persistence for disaster recovery.

How many replicas can I have? Technically, thousands, but in practice, you should limit the number to prevent excessive network bandwidth consumption on the master during initial sync.

Can I chain replicas? Yes. You can have a "replica of a replica." This is useful for distributing the load of the initial synchronization process.

Recap

In this lesson, we established that replication is the primary mechanism for scaling reads and improving availability. We configured a master-replica pair, verified the status via INFO, and discussed why manual failover is insufficient for production-grade high availability.

Up next: We will look at how to analyze memory usage and identify large keys that could be slowing down your replication stream.