Master‑Slave Replication in Redis: How to Ensure High Availability and Data Consistency

In earlier articles we introduced Redis persistence mechanisms (RDB snapshots and AOF logs) that protect data after a crash. However, persistence alone does not guarantee high availability, as downtime still impacts the business.

Redis offers three high‑availability patterns: master‑slave, Sentinel, and Cluster. This article focuses on the master‑slave mode, where the master (master) replicates data to one or more slaves (slave) via one‑way replication.

To improve availability and balance load, applications typically adopt a read‑write separation model: reads can be served by both master and slaves (usually by slaves), while writes are directed only to the master and then propagated to the slaves.

2.1 Read‑Write Separation Mode

The purpose mirrors MySQL read‑write splitting: allowing multiple slaves prevents write conflicts and ensures data consistency, because only the master handles writes. Enforcing strict ordering or using queues would degrade Redis performance.

2.2 Significance of Master‑Slave Replication

Fault isolation and recovery : If a master or any slave fails, the remaining nodes keep the service running and can be manually or automatically promoted.

Read‑write isolation : The master handles writes, slaves handle reads, distributing traffic and balancing load.

High‑availability guarantee : Master‑slave is the foundational HA model, prerequisite for Sentinel and Cluster modes.

3.1 Master Configuration

<code># Set the IP address and port Redis listens on (default all IPs, port 6379)
bind 0.0.0.0

# Disable protected mode to allow remote access
protected-mode no

# Specify the listening port for the master
port 6380

# Increase max memory (adjust to your server)
maxmemory 20480mb</code>

3.2 Slave Configuration

Add the following to the slave's redis.conf :

<code>replicaof <masterip> <masterport></code>

Assuming a master at 10.21.125.1:6380 and two slaves at 10.21.125.2:6379 and 10.21.125.3:6379, execute on each slave:

<code># Set slave listening port
port 6379

# Point to the master for replication
replicaof 10.21.125.1 6380</code>

4.1 Synchronization Mechanism

Redis uses asynchronous (optimistic) replication, which cannot guarantee real‑time consistency. The PSYNC command orchestrates synchronization in several scenarios:

Initial full sync : When a slave first connects, it issues PSYNC -1 and receives a complete copy of the master’s data.

Steady‑state incremental sync : The master streams new write commands from its replication buffer to the slave.

Reconnection after interruption : The slave sends PSYNC runid offset ; if the master still holds the offset in its backlog, it replies CONTINUE and sends only the missing commands.

Full resync trigger : If the runid mismatches or the offset is out of range, the master replies with FULLRESYNC runid offset , prompting a new full copy.

The replication buffer (repl_backlog) stores recent write commands so that reconnecting slaves can catch up without a full transfer, preserving efficiency and consistency.

4.2 One Master Multiple Slaves Synchronization Details

Each slave tracks its own slave_repl_offset indicating how much data it has received.

During reconnection, the slave reports this offset via PSYNC; the master decides whether incremental or full sync is needed.

The master maintains a shared repl_backlog_buffer for all slaves, while a temporary buffer handles the initial full copy for each connecting slave.

Summary

Master‑slave replication distributes read/write load and ensures service continuity after node failures.

The replication process consists of connection establishment, data synchronization (full or incremental), and continuous command propagation over a long‑lived connection.

Full sync occurs on the first connection or after a prolonged disconnection; incremental sync handles regular updates.

For automatic failover, monitoring, and higher availability, Sentinel or Cluster modes are required beyond basic master‑slave.