Sentinel

Introduction

Replication gives you redundant copies of data, but it does not automate failover. If the master crashes, someone—or something—must promote a replica and redirect clients. Redis Sentinel is that something. It monitors your master and replicas, detects failure, and orchestrates an automatic promotion with minimal human intervention. This chapter explains how to deploy, configure, and reason about Sentinel in production.

Prerequisites

Completion of Replication
At least one master and one replica running (three Redis instances total are recommended)
Understanding of TCP ports and basic networking

What Sentinel Does

Sentinel is a distributed system itself. You run multiple Sentinel processes (typically three or five) that collectively agree on the state of your Redis deployment. Their responsibilities are:

Monitoring: Ping masters and replicas continuously.
Notification: Alert administrators when something goes wrong.
Auto-failover: Promote the best replica to master and reconfigure other replicas to follow it.
Configuration provider: Clients ask Sentinels for the current master address instead of hard-coding it.

plaintext

┌─────────┐     ┌─────────┐     ┌─────────┐
│Sentinel1│────→│Sentinel2│────→│Sentinel3│
└────┬────┘     └────┬────┘     └────┬────┘
     │               │               │
     └───────────────┼───────────────┘
                     │
              ┌──────┴──────┐
              ↓             ↓
         ┌─────────┐   ┌─────────┐
         │ Master  │──→│ Replica │
         │  :6379  │   │  :6380  │
         └─────────┘   └─────────┘

Sentinel Configuration

Create a minimal sentinel.conf for each Sentinel node. The only mandatory field is the master name and location.

conf

Start Sentinel:

bash

redis-sentinel /path/to/sentinel-26379.conf

Or with redis-server in Sentinel mode:

bash

redis-server /path/to/sentinel-26379.conf --sentinel

The Quorum and Consensus

The quorum (the number after the port in sentinel monitor) controls two distinct things:

Failure detection: At least quorum Sentinels must agree the master is unreachable before it is declared objectively down.
Failover authorization: A Sentinel needs a majority of all known Sentinels (not just the quorum) to actually perform the failover.

Tip

Odd Numbers Only

Always deploy an odd number of Sentinel instances—three or five. Even numbers (two, four) can create split-brain situations where no side has a majority.

Failure Detection: SDOWN vs ODOWN

Sentinel uses two levels of failure detection:

Subjectively Down (SDOWN): A single Sentinel cannot reach the master within down-after-milliseconds. This is one Sentinel's local opinion.
Objectively Down (ODOWN): Enough Sentinels (quorum or more) also report the master as SDOWN. Only then is failover considered.

This two-step process prevents a single network partition or overloaded Sentinel from triggering an unnecessary promotion.

The Failover Process

Once a master is ODOWN, the Sentinel that detected it requests authorization from the others. If granted, it executes these steps:

Select the best replica based on priority, replication offset, and run ID.
Send REPLICAOF NO ONE to the chosen replica, promoting it to master.
Send REPLICAOF new_master_ip new_master_port to all remaining replicas.
Update its own internal view so that future client queries return the new master address.
Optionally execute a user-defined script to notify external systems.

The old master, if it recovers, is reconfigured as a replica of the new master.

Connecting Clients to Sentinel

Hard-coding the master IP in your application is fragile. Instead, clients should query Sentinel for the current master.

bash

# Ask Sentinel for the current master address
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# 1) "127.0.0.1"
# 2) "6380"

Most Redis client libraries (Jedis, Lettuce, redis-py, StackExchange.Redis) support Sentinel natively. You provide a list of Sentinel addresses and a master name; the library handles discovery, failover, and reconnection automatically.

python

# Example with redis-py
from redis.sentinel import Sentinel
 
sentinel = Sentinel([
    ('sentinel1.example.com', 26379),
    ('sentinel2.example.com', 26379),
    ('sentinel3.example.com', 26379)
])
 
# Returns a client connected to the current master
master = sentinel.master_for('mymaster', socket_timeout=0.5)
master.set('key', 'value')

Warning

Client Side Caching

Client libraries cache the master address for performance. During failover, there is a brief window where a client may write to the old master before it learns about the promotion. Good clients detect the READONLY error and refresh their cache immediately.

Monitoring Sentinel Itself

bash

# List all Sentinels watching this master
redis-cli -p 26379 SENTINEL sentinels mymaster
 
# Check the master state
redis-cli -p 26379 SENTINEL master mymaster
 
# List replicas
redis-cli -p 26379 SENTINEL replicas mymaster
 
# Check Sentinel info
redis-cli -p 26379 INFO sentinel

Key fields to monitor:

num-other-sentinels: Should match your deployment size minus one.
flags: master when healthy, master_down or s_down during outages.
failover-state: Empty when idle; other values during active failover.

Sentinel Best Practices

Practice	Rationale
Run Sentinel on separate machines from Redis	Prevents a single hardware failure from taking down both data and monitoring
Use at least three Sentinels	Provides quorum without excessive coordination overhead
Set `down-after-milliseconds` conservatively	Too low causes false positives; too high extends downtime
Configure `parallel-syncs` carefully	Higher values speed up failover but spike network and disk I/O
Test failover before going live	Run `SENTINEL failover mymaster` manually and verify client behavior

FAQ

Can Sentinel monitor multiple independent masters?

Yes. Add multiple sentinel monitor lines to the same configuration file. Sentinel tracks each master as an independent group.

What happens if all Sentinels crash?

Redis itself continues running. Replication keeps working in the current state. However, automatic failover stops until at least a quorum of Sentinels recovers. This is another reason to run Sentinels on stable infrastructure.

Does Sentinel guarantee zero data loss?

No. Because Redis replication is asynchronous, a replica may be slightly behind the master at the moment of failure. The promoted replica contains everything up to its last received offset. The small window of unsynced writes is lost unless you use synchronous replication (WAIT), which trades availability for consistency.

How do I force a manual failover?

bash

redis-cli -p 26379 SENTINEL failover mymaster

This is useful for planned maintenance, such as upgrading the master server hardware. The failover proceeds automatically, and you can verify the new topology before touching the old master.

Can I run Sentinel and Redis on the same server in production?

You can, but you should not. Collocating them saves machines but creates a single point of failure. If the server dies, you lose both the data node and a Sentinel, reducing your quorum and failover reliability.