Mastering Redis Replication: Features, Mechanics, and Deployment Guide

Redis Replication Features

A single master can have multiple slaves.

Slaves can also accept connections and sync requests from other slaves, enabling cascading replication (master → slave → sub‑slave).

The master synchronizes data to slaves in a non‑blocking way, allowing it to continue handling read/write requests from other slaves.

Slaves can serve queries using the previous dataset while a new sync is in progress; if the connection to the master is lost, the slave returns an error to the client.

Replication provides scalability: multiple slaves handle read‑only queries and data redundancy, while the master handles write operations, achieving read/write separation and load balancing.

By disabling persistence on the master and delegating persistence to slaves, the master avoids running a separate persistence process.

Replication Process and Key Points

When a Redis instance starts with slaveof <master_ip> <port>, it sends a SYNC command to the master to request synchronization.

The master receives SYNC, replies with a PING, and runs bgsave to create an RDB snapshot while buffering subsequent write commands.

After persisting the snapshot to disk, the master sends the RDB file to the slave.

The slave saves the file, loads it into memory, completing the initial full synchronization.

The master then streams the buffered write commands to the slave, keeping them in sync.

The slave executes these commands locally, similar to MySQL's sql_thread, achieving eventual consistency.

If the connection breaks, the slave automatically reconnects. Before Redis 2.8, reconnection triggers a full sync; from 2.8 onward, a partial sync is attempted.

Safety When Master Persistence Is Disabled

Disabling the master’s persistence may improve latency, but if the master crashes, it restarts with an empty dataset. Slaves will then replicate this empty dataset, overwriting their own data and causing total data loss. Even HA tools like Sentinel cannot detect such rapid failures.

Partial Resynchronization (PSYNC)

From Redis 2.8, the PSYNC command enables partial resynchronization. Older slaves that only support SYNC will fall back to a full sync.

Disk‑less Replication

Normally replication creates an RDB file on disk before sending it to slaves. Starting with version 2.8.18, an experimental disk‑less mode streams the RDB directly to slaves without intermediate storage, reducing I/O pressure on the master.

Deployment Guide

Environment

Master (rac4): 10.0.2.8:6379

Slave (rac3): 10.0.2.6:6379

Steps:

Prepare two machines (or two ports on one machine) as described in the “Redis Intro” guide.

Edit redis.conf on the slave to add slaveof 10.0.2.8 6379. Alternatively, start the slave and run slaveof 10.0.2.8 6379 manually. Note that the relationship is lost after a slave restart unless the configuration is persisted.

Start both instances, e.g., /usr/local/bin/redis-server /etc/redis/redis.conf. After this, rac4 acts as the master and rac3 as its replica.

Application Example

Master node screenshot:

Slave node screenshot:

Further Reading

For a complete overview of Redis high‑availability, see the official Redis replication documentation and explore the relationship between replication and persistence mechanisms such as RDB and AOF.