How Redis Sentinel Guarantees Automatic Failover and High Availability

This article examines how Redis achieves automatic fault recovery, building on data persistence and multi‑replica setups.

Deployment Modes

Redis can be deployed in several ways, each offering a different level of availability.

Single‑node deployment: a single instance handles all reads and writes; if it crashes, all data is lost.

Master‑slave deployment: a master handles writes while slaves serve reads; manual promotion of a slave is required when the master fails.

Master‑slave + Sentinel deployment: adds a group of Sentinel nodes that continuously monitor the master and automatically promote a slave to master when needed, minimizing downtime.

Thus, high availability relies on multiple replicas and automatic failover.

High Availability Approach

Redis provides native master‑slave replication to keep slaves synchronized with the master.

When the master fails, a slave must be promoted; Sentinel automates this promotion to reduce manual intervention.

Sentinel Overview

Sentinel is a service that monitors Redis instances, sends notifications, and performs automatic failover.

By configuring the master in Sentinel’s configuration file, Sentinel manages the cluster and ensures high availability.

Multiple Sentinel nodes are deployed to avoid false positives caused by network partitions; they exchange health information and collectively decide on failures.

Sentinel Working Principle

The workflow consists of several stages:

State awareness

Heartbeat detection

Sentinel leader election

Selecting a new master

Failover

Client awareness of the new master

State Awareness

Sentinels periodically send INFO commands to masters to obtain the full topology, including slave addresses, and store this information for future failover decisions.

They also publish master status and their own information via a Pub/Sub channel, allowing other Sentinels to receive updates.

Detect other Sentinels joining the cluster, facilitating communication.

Exchange master status to determine whether a master is truly down.

Heartbeat Detection

Each Sentinel pings masters, slaves, and other Sentinels every second; lack of response marks a node as subjectively down.

Only when a configurable majority of Sentinels agree is the node considered objectively down.

Sentinel Leader Election

Sentinels run a consensus algorithm similar to Raft to elect a leader that coordinates the failover.

The election involves random timeouts, request/response exchanges, and majority voting; if no majority is reached, a new election is triggered.

Selecting a New Master

The elected leader chooses a slave based on slave‑priority, data completeness, and the smallest runid when other criteria are equal.

Promoting the New Master

The leader sends SLAVEOF NO ONE to the selected slave, turning it into the new master, then instructs the former slaves to follow the new master with SLAVEOF <newmaster>.

The failed node is demoted to a slave and added to the configuration for future recovery.

Client Awareness

After failover, Sentinel publishes the new master address via Pub/Sub; clients can subscribe to this channel or query Sentinel directly for the current master.

Hook scripts can also be configured to notify clients of the change.

Conclusion

Redis Sentinel ensures high availability by accurately detecting failures, electing a leader through distributed consensus, and swiftly promoting a new master, thereby maintaining service continuity in a distributed environment.