Deep Dive into Redis Replication: Principles, Configuration, and Common Issues

Redis persistence and high‑availability rely on replication to solve the single‑node backup problem; master‑slave replication forms the foundation of Redis HA.

CAP theory states that a distributed system can only simultaneously guarantee two of Consistency, Availability, and Partition tolerance; when a network partition occurs, consistency and availability are mutually exclusive.

Redis implements asynchronous master‑slave replication: the master handles writes, slaves handle reads, achieving eventual consistency while maintaining service availability during network partitions.

Benefits of replication include read/write separation, load balancing, rapid failover, data redundancy, and serving as the basis for Sentinel and cluster solutions.

Replication can be configured in three ways: slaveof (client command), redis-server --slaveof (startup parameter), or by setting slaveof in redis.conf.

Authentication can be set on the master with requirepass (config file or config set requirepass) and on the slave with auth, masterauth, or via redis-cli -a.

Replication proceeds through three stages:

Connection establishment : the slave sends slaveof ip port, the master records the slave’s address, and a heartbeat mechanism is set up.

Data synchronization : the slave issues psync ? -1 for a full sync; the master performs bgsave (copy‑on‑write), sends the RDB file and +FULLRESYNC runid offset. Subsequent partial sync uses psync runid offset and the replication backlog buffer.

Command propagation : after the initial sync, the master streams write commands to slaves; slaves replay them via BGREWRITEAOF.

The runid uniquely identifies a master instance; a change (e.g., after a restart) forces a full resynchronization. The replication backlog buffer stores recent commands with an offset to support partial sync.

Heartbeat mechanisms keep nodes alive: the master sends PING (controlled by repl-ping-slave-period), while slaves send REPLCONF ACK {offset} every second. Configurations like min-slaves-to-write 2 and min-slaves-max-lag 8 protect data integrity when slave count or lag is insufficient.

Common issues include:

Master restart changes runid, triggering full sync; mitigated by preserving master_replid and master_repl_offset.

Too‑small replication backlog causing overflow and frequent full syncs; adjust repl-backlog-size based on workload.

Heavy commands (e.g., KEYS *) on slaves block replication; set appropriate repl-timeout.

Low ping frequency or packet loss leading to disconnections; increase ping rate and set timeout multiples.

Network delays causing stale data; configure slave-serve-stale-data yes|no accordingly.

In summary, the article details the implementation, configuration, and pitfalls of Redis master‑slave replication, laying the groundwork for future discussions on Sentinel and cluster architectures.