Master‑Slave Replication in Redis: How It Works, Configurations, and Pitfalls

Overview

Redis implements asynchronous master‑slave replication. A slave continuously receives a stream of commands from its master. If the network connection drops, the slave automatically reconnects and first attempts a partial resynchronization (PSYNC). When the master’s replication backlog does not contain the missing data, the slave falls back to a full resynchronization.

Key Mechanisms

Continuous command stream from master to slaves while the connection is alive.

Partial resynchronization (PSYNC) after a disconnection, fetching only the missing command range.

Full resynchronization when PSYNC is impossible, which involves generating an RDB snapshot on the master and transferring it to the slave.

Replication Characteristics

Replication is asynchronous; slaves acknowledge receipt of data independently of the master.

One master can have many slaves; slaves can also act as masters for sub‑slaves (Redis 4.0+).

Replication on the master side is non‑blocking; the master continues to serve clients while a full sync is in progress.

On the slave side, the old dataset is kept until the RDB file is received, then the old data is cleared and the new dataset is loaded. This short window may block new connections for large datasets.

Replication can be used for read‑scale‑out, data safety, or high availability.

Configuration Options

Runtime configuration (SLAVEOF command)

Execute SLAVEOF <ip> <port> at runtime. No restart is required, but the setting is not persisted across restarts.

Static configuration (redis.conf)

slaveof <ip> <port>
slave-read-only yes

Changes require a server restart.

Full Synchronization Process

Master runs bgsave to create an RDB snapshot and sets client-output-buffer-limit slave 256mb 64mb 60.

Master streams the RDB file to the slave. If the transfer exceeds repl-timeout, increase the timeout (e.g., on a 1 Gbps link, 6 GB may need >60 s).

Slave writes the RDB to disk, clears its old dataset, and loads the new one into memory.

If the slave has AOF enabled, BGREWRITEAOF is triggered after the RDB load.

Typical full‑sync duration for 4–6 GB of data is 1.5–2 minutes.

Partial Synchronization (PSYNC)

Slave sends PSYNC <runid> <offset>. The master replies with either: FULLRESYNC <runid> <offset> – triggers a full sync. CONTINUE – sends only the missing command stream.

If the requested offset is not present in the master’s backlog, a full resynchronization occurs.

Replication IDs and Offsets

Each master has a unique replication ID (a pseudo‑random string) and a monotonically increasing offset. The master also maintains a circular buffer called the backlog (default 1 MB) that stores recent writes. Slaves report their current offset to the master every second; the master records each slave’s offset to detect divergence.

Diskless Synchronization

Setting repl-diskless-sync yes makes the master generate the RDB snapshot directly in memory and stream it to slaves without persisting it to disk. The optional repl-diskless-sync-delay can delay the start of the sync to allow more slaves to connect.

Key Expiration Handling

Slaves never expire keys locally; they wait for the master to issue a DEL command.

If the master’s DEL is delayed, slaves use a logical clock to hide logically expired keys from reads.

During Lua script execution, key expiration is frozen on both master and slaves.

When a slave is promoted to master, it takes over expiration handling independently.

Safety Considerations

Disabling persistence on a master that may be automatically restarted is unsafe. After a restart the master’s dataset is empty, and any slaves replicating from it will lose their data. The same risk applies when using Redis Sentinel for high availability; automatic process restarts must be disabled if the master’s persistence is disabled.

References

Redis Replication Documentation: https://redis.io/topics/replication

Redis 2.8 Release Notes: https://raw.githubusercontent.com/antirez/redis/2.8/00-RELEASENOTES