Redis Master‑Slave Replication and Sentinel: How They Work and Scale

Master‑Slave Mode

Read/write separation: the master handles both read and write commands, while slaves handle only read commands.

<table><tbody><tr><td>Why is there only one master handling reads? This avoids introducing locks and inter‑instance coordination for modifications.</td></tr></tbody></table>

Master‑Slave Synchronization

Replication is initiated with the replicaof {master_ip} 6379 command, which requests the RDB file from the master.

The slave sends a psync command to the master, indicating a desire to synchronize data. The psync command includes the master’s runID and the replication offset. The runID is a unique identifier generated when the Redis instance starts; for the first replication the master’s runID is unknown and set to “?”. The offset is –1 for the first replication.

The master responds with FULLRESYNC , returning its runID and replication offset, which the slave records.

The master runs bgsave to generate an RDB file and sends it to the slave, which clears its current memory data and loads the RDB.

During synchronization, the master sends any write commands buffered in the replication buffer to the slave, which replays them to complete data sync.

Reducing Master Sync Load

Because bgsave increases CPU and memory usage and briefly blocks the master, a secondary slave can be promoted to act as a master for some slaves, sharing the full‑copy load.

Network Disconnection Handling

Slaves periodically send REPLCONF ACK with their offset to the master. Network jitter may cause the slave’s offset to fall behind.

The master buffers incoming write commands in a circular repl_backlog_buffer and updates its master offset. When a slave reconnects, the master checks whether the backlog still contains the missing offset. If it does, the missing commands are sent from the buffer; otherwise a full sync via bgsave is performed.

1. repl_backlog_buffer
   Circular buffer on the master that records write commands for slave replication; size can be tuned based on TPS, network I/O, and sync latency.

2. replication buffer
   Each slave has its own replication buffer, similar to a client buffer; write commands are first written here before being sent over the socket. When a slave disconnects, the backlog is used to retrieve lost commands.

Sentinel Mode

Sentinel provides automatic failover for Redis master‑slave setups.

It solves three problems: detecting master failure, selecting a new master, and broadcasting the new master’s information to the cluster.

Sentinel Concept

A special Redis instance responsible for monitoring, leader election, and notification.

Monitoring

Sentinels periodically send PING to all masters and slaves, receiving three possible replies:

PONG : normal response, indicating the master is alive.

LOADING : the master is loading data; no further action needed if it later returns PONG.

MASTERDOWN : the master is down, which can be subjectively down (SDOWN) or objectively down (ODOWN). Sentinels coordinate to confirm the state and start failover.

If a slave does not respond in time it is marked subjectively down; if the master does not respond, a failover is triggered.

Subjective vs. Objective Down

When N sentinel instances are running, at least N/2 + 1 must consider the master subjectively down before it is marked objectively down.

Once a sentinel judges the master down, it sends is-master-down-by-addr to other sentinels, which vote Y (agree) or N (disagree). When the required number of votes (configured by quorum) is reached, the master is marked objectively down.

Leader Election

Sentinel Lead Election

A sentinel can become leader only if it obtains a majority of votes and the vote count meets or exceeds the quorum value.

Promoted Slave Selection

Higher slave‑priority yields a higher score.

Closer replication offset to the old master yields a higher score.

Smaller instance ID yields a higher score.

Notification

After a new master is elected, sentinels broadcast its connection info to other slaves (which run replicaof to sync) and to clients (via redis‑cli or SDK) so that all traffic is redirected to the new master.

Pub/sub based sentinel cluster.

INFO‑based slave list for establishing connections.

Sentinel’s own pub/sub for client‑sentinel event notifications.

Source: https://www.cnblogs.com/kiper/p/17809060.html (© original author).