Mastering Redis Master‑Slave Replication: Core Concepts, Workflow, and Configuration

Core Benefits of Redis Master‑Slave Replication

Hot backup & reliability : The replica maintains a real‑time copy of the master, providing an off‑site hot backup that can be used for rapid recovery after hardware failure or accidental data loss.

Read‑write separation : Writes are handled only by the master, while replicas serve the majority of read traffic. This reduces master load and increases overall read throughput, which is essential for read‑heavy workloads such as e‑commerce catalog queries or news‑feed browsing. Replication is asynchronous, so replicas may lag by a few milliseconds – acceptable for caching or reporting but not for strict financial transactions.

High‑availability foundation : Sentinel and Redis Cluster rely on replication. If the master crashes, Sentinel can automatically promote a healthy replica to master, ensuring continuous service.

Horizontal scaling : Adding more replicas linearly increases read capacity without upgrading the master’s hardware, offering a cost‑effective way to handle traffic growth.

Replication Workflow (Three Stages)

Stage 1 – Connection Establishment & Configuration

Configure the replica in redis.conf with replicaof <master‑IP> <port> or issue the REPLICAOF command at runtime.

The replica opens a TCP socket to the master and sends a PING command to verify connectivity.

If the master requires authentication ( requirepass), the replica sends AUTH <password>.

The replica starts listening on its replication backlog buffer and waits for the master to push data.

Stage 2 – Data Synchronization

Since Redis 2.8 the PSYNC command replaces the older SYNC, enabling partial resynchronization and faster reconnections.

Full Synchronization (initial or after long disconnection)

Replica sends PSYNC ? -1 to request a full sync.

Master runs BGSAVE to create an RDB snapshot while buffering new write commands in the replication backlog.

Master streams the RDB file to the replica; the replica clears its existing dataset and loads the snapshot.

Master then streams the buffered write commands; the replica executes them, achieving full data parity.

Partial Synchronization (short reconnection)

Replica sends PSYNC <master‑ID> <current‑offset> indicating the last processed offset.

Master validates the ID and offset, replies +CONTINUE, and streams only the missing commands.

Replica executes the received commands, catching up to the latest state.

Key Concepts

Replication offset : A monotonically increasing counter on both master and replica that tracks the number of bytes transferred.

Replication backlog : The master’s in‑memory command buffer (default 1 MB, configurable via repl-backlog-size) that stores recent writes for partial sync.

Server run‑ID : A unique identifier generated at startup; a change forces a full sync because replicas can no longer match the previous ID.

Stage 3 – Command Propagation

After synchronization, every write command executed on the master (e.g., SET, DEL, LPUSH) is sent asynchronously to all replicas. Each replica applies the command locally, keeping its dataset identical to the master. Because the master does not wait for acknowledgments, there is a tiny window of possible data loss if the master crashes immediately after sending a command.

Practical Configuration Options

Asynchronous replication (default) : Provides the best performance; accepts millisecond‑level replication lag.

Minimum replicas to write : Set min-replicas-to-write <N> and min-replicas-max-lag <seconds> to reject writes when fewer than N healthy replicas are connected or when lag exceeds the specified threshold, thereby favoring consistency.

Disk‑less replication : Enable repl-diskless-sync yes to generate the RDB snapshot in memory and stream it directly to replicas, useful when disk I/O is a bottleneck (e.g., shared cloud disks).

Cascading replication : Replicas can themselves act as masters for other replicas, forming a tree (master → replica → sub‑replica) that reduces load on the primary and scales to large numbers of replicas.

By understanding these mechanisms and tuning the relevant parameters, operators can build Redis deployments that combine high performance, fault tolerance, and scalable read capacity.