Understanding Redis Master‑Slave Replication: Principles, Configuration, Workflow, and Common Pitfalls

1. CAP Theory

The CAP theorem states that a distributed storage system must trade off between Consistency (C), Availability (A), and Partition tolerance (P); when a network partition occurs, a system cannot guarantee both consistency and availability simultaneously.

2. Redis Master‑Slave Replication

2.1 Overview

Redis achieves high concurrency and performance while high availability relies on master‑slave replication. The master handles write operations, slaves handle read operations, and replication is asynchronous, providing eventual consistency.

2.2 Benefits

Read‑write separation: master writes, slaves read, improving load capacity.

Load balancing: multiple slaves share read traffic, increasing throughput.

Failover: slaves can take over when the master fails.

Data redundancy: hot backup beyond persistence.

Foundation for high‑availability solutions such as Sentinel and Cluster.

2.3 Configuration Methods

Redis supports three ways to configure replication:

Client command: slaveof <masterip> <masterport>

Server start‑up flag: redis-server -slaveof <masterip> <masterport>

Configuration file (redis.conf): slaveof <masterip> <masterport>

Authentication can be set on the master with requirepass <password> or config set requirepass <password> , and on the slave with auth <password> , masterauth <password> , or redis-cli -a <password> .

2.4 Replication Workflow

2.4.1 Connection Establishment

The slave sends slaveof ip port to the master, the master records the slave’s port, and a socket connection is created. Heartbeat and optional authentication follow.

2.4.2 Data Synchronization

The slave initiates a full sync with psync ? -1 . The master performs a background save (bgsave) to generate an RDB snapshot using Copy‑On‑Write, streams any writes to the replication backlog, and sends the RDB file together with +FULLRESYNC <runid> <offset> . After loading the RDB, the slave requests incremental updates with psync <runid> <offset> . If the backlog overflows, the master falls back to a full resync.

2.4.3 Command Propagation

During the command propagation phase, the master forwards write commands to slaves based on the slaves’ reported offsets. Slaves replay received commands using bgrewriteaof . If a network partition or offset overflow occurs, a full resync is triggered.

2.5 Heartbeat Mechanism

The master sends PING at intervals defined by repl-ping-slave-period (default 10 s). Slaves report their offset with REPLCONF ACK {offset} every second. These heartbeats allow both sides to detect offline peers and maintain synchronization.

3. Common Issues and Mitigations

Master restart: Run‑id changes cause full resync. Preserve master_repl_id and master_repl_offset in the RDB and reload on restart.

Backlog too small: High write concurrency can overflow the replication backlog, forcing full sync. Adjust repl-backlog-size based on workload.

Blocking commands on slave: Commands like keys * or hgetall block replication. Set an appropriate repl-timeout to release unresponsive slaves.

Insufficient master ping frequency: Increase ping rate or set repl-timeout to 5‑10 × the ping interval to tolerate packet loss.

Network latency: Use slave-serve-stale-data yes|no to control whether stale reads are allowed, and monitor info replication lag values.

4. Summary

Redis master‑slave replication is a fundamental building block for high availability; understanding its CAP‑theoretic background, configuration options, three‑stage workflow, heartbeat, and common pitfalls helps engineers design robust Redis deployments. Future articles will cover Sentinel and Cluster setups.