Master‑Slave Replication in Redis: Mechanisms, Sync Types, and Configuration Guide

Overview of Redis Replication

Redis replication creates one or more slave instances that maintain an exact copy of a master instance. If the connection between master and slave breaks, the slave automatically reconnects and attempts to become an exact replica of the master.

Core Mechanisms

Update slave – While the master‑slave connection is healthy, the master continuously streams command logs (writes, key expirations, evictions) so the slave stays up‑to‑date.

Partial resynchronization – After a disconnection, the slave requests only the command stream that was missed during the outage.

Full resynchronization – If partial sync is not possible, the master creates an RDB snapshot of the entire dataset, streams it to the slave, and then continues sending new command logs.

Characteristics of Redis Replication

Replication is asynchronous by default, providing low latency and high throughput.

A single master can have multiple slaves; slaves can also act as masters for other slaves (sub‑slaves).

Replication on the master side is non‑blocking – the master continues to serve queries during initial or partial sync.

On the slave side most operations are non‑blocking, but loading a new RDB snapshot temporarily blocks client connections.

Typical uses include read‑scaling, data safety, and high availability.

By disabling disk persistence on the master (e.g., save "" in redis.conf) and enabling persistence only on a slave, write‑amplification to disk can be reduced. This must be done carefully because a master restart without a persisted dataset will start from an empty state.

Implementation

Command: SLAVEOF

SLAVEOF <em>ip</em> <em>port</em>

Configuration

Set the slave to reject write commands: slave-read-only yes After changing redis.conf, restart the instance for the setting to take effect.

Full Synchronization Process

The master runs bgsave to generate an RDB snapshot.

The snapshot is streamed to the slave. If the transfer exceeds repl-timeout, the slave marks the sync as failed.

During snapshot creation, the master buffers incoming write commands in memory.

After the slave saves the RDB file, it deletes its old dataset, loads the new RDB into memory, and continues serving requests based on the old version until the load completes.

If the slave has AOF enabled, it immediately runs BGREWRITEAOF to rewrite the AOF file.

Cost of Full Synchronization

Time to generate the RDB file (bgsave).

Network transfer time for the RDB file.

Time for the slave to delete its old dataset.

Time for the slave to load the new RDB into memory.

Potential AOF rewrite time.

Incremental Replication

If the network connection breaks during a full sync, the slave reconnects and triggers incremental replication.

The master retrieves the missing portion of the command backlog and streams it to the slave.

The slave uses the offset reported in the PSYNC request to request the appropriate slice from the master’s backlog.