Redis master-slave replication enables data from one Redis server (the master) to be copied to one or more other Redis servers (slaves). Data flows unidirectionallly—from master to slave. By default, every Redis instance starts as a master. A master can have multiple slaves, but each slave can only replicate from a single master.

Key Benefits of Replication

• Data Redundancy: Provides hot backup of data beyond standard persistence mechanisms.
• Fault Tolerance: Slaves can take over read operations if the master fails, enabling faster recovery.
• Load Balancing: With read-write splitting, write operations go to the master while reads are distributed across slaves—ideal for read-heavy workloads like e-commerce product catalogs.
• Foundation for High Availability: Essential for implementing Redis Sentinel and Redis Cluster architectures.

Running a single Redis instance in production is discouraged due to single-point-of-failure risks and memory limitations—typically, no more than 20GB per instance is recommended for stability.

Configuration Setup

Only slave instances require configuration; the master needs no special setup. To demonstrate a one-master-two-slaves topology, three Redis instances are launched on ports 6379 (master), 6380, and 6381 (slaves).

Each instance uses a dedicated configuration file with unique settings:

# redis-6379.conf
port 6379
daemonize yes
pidfile /var/run/redis/redis-server_6379.pid
logfile /var/log/redis/redis-server_6379.log
dbfilename dump_6379.rdb

# redis-6380.conf
port 6380
daemonize yes
pidfile /var/run/redis/redis-server_6380.pid
logfile /var/log/redis/redis-server_6380.log
dbfilename dump_6380.rdb

# redis-6381.conf
port 6381
daemonize yes
pidfile /var/run/redis/redis-server_6381.pid
logfile /var/log/redis/redis-server_6381.log
dbfilename dump_6381.rdb

After starting all three services, verify their initial state using:

INFO REPLICATION

Each will report role:master and zero connected slaves.

Establishing Replication

To configure slaves, connect to each slave instance and issue the REPLICAOF command (note: SLAVEOF is deprecated in newer versions):

127.0.0.1:6380> REPLICAOF 127.0.0.1 6379
OK

127.0.0.1:6381> REPLICAOF 127.0.0.1 6379
OK

Re-running INFO REPLICATION on the master now shows two connected replicas. Slaves become read-only; any write attempt returns an error.

Note: Command-line replication is temporary. For persistent configuration, add the following line to each slave’s config file:

replicaof 127.0.0.1 6379

If the master requires authentication, also include:

masterauth <password>

Replication Mechanics

When a replica connects to a master:

1. The replica sends a SYNC (or PSYNC in modern vertions) request.
2. The master triggers a background save (RDB snapshot) and buffers all incoming write commands.
3. Once the snapshot is ready, the master transfers the RDB file to the replica (full resynchronization).
4. The replica loads the RDB into memory and applies the buffered commands.
5. Thereafter, the master streams new write commends incrementally (partial resynchronization).

If a replica disconnects and reconnects, a full sync may be triggered again unless partial resync conditions are met (e.g., via replication backlog).