Understanding Redis Sentinel: High‑Availability Mechanism and Automatic Failover

Overview

We know that master‑slave replication is the foundation of high availability: if a replica fails, requests can be redirected to the master or another replica, but if the master fails, only read operations are possible and write requests cannot be executed.

The master‑slave architecture faces a serious problem: when the master crashes, write operations cannot be performed and there is no automatic way to promote a slave to master, i.e., no automatic failover.

Manually switching master in the middle of the night is impractical, so Redis provides a built‑in high‑availability solution – Sentinel .

What is Sentinel?

Sentinel is a special department that monitors the health of the master and replicas, and when the master is deemed down, it automatically promotes a suitable replica to become the new master and notifies all clients.

In a typical deployment, three Sentinel instances form a cluster monitoring a three‑node Redis setup (one master, two replicas).

Sentinel’s Main Tasks

Sentinel focuses on monitoring the runtime status of Redis instances (master and replicas) and, when the master fails, it performs automatic failover to ensure system availability. According to the official Redis documentation ( https://redis.io/topics/sentinel ), Sentinel provides three core capabilities:

Monitoring : continuously checks whether master and replicas are operating as expected.

Automatic master switch : when the master is faulty, Sentinel selects a replica to become the new master.

Notification : instructs replicas to execute replicaof and informs clients to connect to the new master.

How Sentinel Detects Failures

Sentinel sends a PING command to every node once per second. If a replica does not respond within the configured time, Sentinel marks it as subjectively down . If the master does not respond, Sentinel marks it as subjectively down and starts the failover process.

Two concepts are used to avoid false positives:

Subjective Down

When a Sentinel receives an invalid reply from a node, it marks that node as subjectively down. For a replica, this is sufficient; for a master, additional confirmation is required before proceeding.

Objective Down

Only when a majority of Sentinels (quorum) agree that the master is subjectively down does the master become objectively down, triggering the failover.

The quorum is defined in the Sentinel configuration, e.g.:

# sentinel monitor <master-name> <master-host> <master-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

Automatic Master Switch

After the master is objectively down, Sentinel selects a new master based on a three‑step scoring system:

Slave priority : the slave-priority setting gives higher‑priority replicas a direct advantage.

Replication offset : compare slave_repl_offset with master_repl_offset; the replica whose data is most up‑to‑date wins.

Run ID : if the previous criteria tie, the replica with the smallest runid (older instance) is chosen.

Notification Mechanism

Once a new master is elected, Sentinel notifies all replicas and clients via Pub/Sub channels. Important events include: +sdown / -sdown: replica enters/exits subjective down. +odown / -odown: master enters/exits objective down. +slave-reconf-sent, +slave-reconf-inprog, +slave-reconf-done: replica reconfiguration progress. +switch-master: master address change.

Clients can subscribe to these channels, e.g. SUBSCRIBE +odown, to react to failover events.

Configuration Tips

down‑after‑milliseconds

This option defines how long a Sentinel must wait for a valid reply before marking a node subjectively down. All Sentinels should share the same value to avoid split‑brain scenarios.

down‑after‑milliseconds * 10

If a replica experiences more than ten consecutive timeouts, it is considered unreliable and excluded from master election.

Summary

Redis Sentinel provides a robust high‑availability solution by continuously monitoring master and replica health, automatically promoting a suitable replica when the master fails, and notifying all participants of the new topology. Deploying an odd number of Sentinels (typically three) ensures quorum‑based decision making and reduces the risk of false failovers.