Understanding Redis Master‑Slave Replication: Architecture, Setup, and Mechanisms

This article explains Redis high availability via master‑slave replication, detailing concepts, configuration, synchronization phases, buffer handling, and practical considerations.

1. Overview of Master‑Slave Replication

Redis offers a master‑slave mode where data is copied from a master node to one or more slave nodes. The master handles all write operations, while slaves can serve read requests, providing fault tolerance and load balancing.

2. Setting Up Replication

Replication is initiated from the slave using the replicaof command (or slaveof in older versions). There are three ways to enable it:

Add replicaof <masterip> <masterport> to the slave's configuration file.

Start the slave with --replicaof <masterip> <masterport> as a server option.

Run the command at runtime: replicaof <masterip> <masterport> .

replicaof 172.16.88.1 6379

3. Replication Mechanism

Replication consists of three phases: connection establishment, data transfer (full sync), and command propagation (incremental sync).

Full Synchronization

During the first sync the master executes bgsave to generate an RDB file, sends the file to the slave, and records all subsequent write commands in a replication buffer. The slave clears its current DB, loads the RDB, and then receives the buffered writes.

The slave initiates the process with psync . The master replies with FULLRESYNC <runID> <offset> , indicating a full copy.

Incremental Synchronization

After the initial copy, the master keeps recent writes in a circular repl_backlog_buffer . If the network disconnects, the slave can request missing data using its stored runID and offset. If the required data is still in the backlog, the master replies with CONTINUE for a partial sync; otherwise it falls back to a full sync.

config set client-output-buffer-limit "slave 536870912 536870912 0"

Command Propagation over a Persistent Connection

The master periodically sends PING to detect timeouts, while the slave sends REPLCONF ACK <replication_offset> to acknowledge received data and assist in heartbeat detection.

4. Practical Issues

Read‑write separation can lead to stale reads if slaves do not delete expired keys; since Redis 3.2 slaves check expiration on read and delete if necessary. Large memory usage can slow full sync and cause repeated timeouts, especially when the master must fork to create the RDB file.

Conclusion

Master‑slave replication provides fast recovery and read scaling but has limitations such as lack of automatic failover, write load balancing, and single‑node memory constraints. These issues are addressed by higher‑level solutions like Redis Sentinel and Redis Cluster.

References:

Redis Design and Implementation (Huang Jianhong)

Redis Replication – redis.io/topics/replication

Designing Redis Replication Partial Resync – antirez.com/news/31

Redis Core Technology and Practice – geekbang.org