Mastering Redis Master‑Slave Replication: How It Works and Why It Matters

1. Introduction

Previously we discussed Redis data‑structure internals and persistence; this article focuses on Redis high‑availability.

Time‑travel machine: Redis persistence overview (previous article) Redis data‑structure fundamentals (previous article)

To achieve high availability, a database must ensure data safety and continuous service. Redis, as an efficient caching database, follows the same principles.

The persistence strategy discussed earlier reduces data loss after a crash and enables fast recovery, which is one aspect of high availability.

Beyond persistence, Redis provides three widely used high‑availability mechanisms: master‑slave replication, Sentinel, and Cluster. This article concentrates on master‑slave replication, a frequent interview topic.

2. Master‑Slave Replication Overview

Redis supports both master‑slave replication and read‑write separation: a Master instance handles write operations, while one or more Slave instances replicate the master’s data.

2.1 Architecture Components

Master Node

Data updates: The master processes all write operations (insert, update, delete).

Data synchronization: After a write, the master synchronizes the result to all slave nodes via replication.

Slave Node

Data reads: Slaves handle read operations such as queries.

Data synchronization: Slaves copy data from the master and keep a local data replica.

2.2 Why Use Read‑Write Separation

1) Prevent Concurrency Issues

If both master and slaves could write, data consistency would be hard to guarantee, especially across distributed nodes where locking would introduce latency and lower throughput.

Redis, being a high‑performance cache, cannot afford the performance penalty of locking.

2) Easy Scalability

Most Redis workloads are read‑heavy, write‑light. Adding more slaves scales read capacity and provides data backup and load balancing, improving reliability and performance.

3) High‑Availability Guarantees

Manual master‑slave switching enables fault isolation and recovery; if either master or slave fails, the remaining nodes keep the service running.

3. Implementing Master‑Slave Replication

3.1 Enabling Replication

Use the replicaof command (or slaveof in Redis 5.0 and earlier) on a slave, specifying the master’s IP and port:

replicaof <masterIP> <masterPort>

Note: In Redis 5.0 and earlier the command is slaveof .

After enabling replication, writes go to the master, reads to the slaves. The master and slaves maintain eventual consistency: updates on the master are propagated to the slaves.

3.2 Replication Process

The initial synchronization consists of three stages.

1) Connection Establishment

The slave connects to the master and sends a PSYNC request containing its runID and offset.

runID: Unique identifier of the master instance. During the first sync it is ?.

offset: Sync offset; initially -1 indicating a full sync.

The master creates a replication thread, records the slave’s offset, and starts an RDB sync.

2) RDB Synchronization

The master generates an RDB snapshot (via bgsave and fork) and sends it to the slave. The slave clears its data, loads the RDB file, and replaces its dataset with the master’s.

During this period the master continues to accept writes; new writes are not in the RDB file.

3) Command Propagation

After the RDB file is transferred, the master streams the writes that occurred during the snapshot to the slave, ensuring the slave’s dataset matches the master’s.

3.3 Incremental Synchronization

1) Command Propagation

Once the full sync is complete, the master keeps a TCP connection to the slaves and continuously forwards write commands (asynchronous replication) so the datasets stay consistent.

2) Handling Network Interruptions

If the connection drops, writes on the master are not immediately sent to the slave. When the network recovers, the slave sends psync runid offset to request missing data.

The master verifies the runID and offset, replies with continue, and streams the missed commands.

Redis 2.8+ stores recent writes in the repl_backlog_buffer (replication backlog). The master’s master_repl_offset and the slave’s slave_repl_offset track progress. If the backlog overwrites older data, a full sync is required.

Note: Incremental replication always uses the repl_backlog_buffer circular buffer.

4. Summary

Redis master‑slave replication provides easy scalability and fault isolation: when the master fails, a slave can be promoted quickly, minimizing downtime. The initial sync includes connection establishment, RDB sync, and command propagation. Subsequent synchronization relies on incremental replication controlled by replication offsets and the backlog buffer.