Sentinel

Introduction

Redis Sentinel monitors masters and replicas, performs automatic failover, and publishes new master address to clients — manual promotion takes minutes; Sentinel targets sub-minute RTO for single-master setups.

Deploy at least three Sentinel processes for quorum — odd count avoids split vote. Sentinels are lightweight but must reach majority to authorize failover.

Not for horizontal write scaling — use Cluster for sharding; Sentinel for HA single master.

Understanding the topic

Key concepts

• sentinel monitor mymaster ip port quorum.
• Quorum — min Sentinels agreeing master down.
• Automatic promotion of best replica.
• Sentinel publishes +switch-master event.
• Clients subscribe or use Sentinel-aware driver.
• Configuration epoch tracks failover generation.

flowchart TB
  S1[Sentinel 1] --> M[Master]
  S2[Sentinel 2] --> M
  S3[Sentinel 3] --> M
  M --> R1[Replica]
  M --> R2[Replica]
  S1 -.->|failover| R1

Step-by-step explanation

1. Sentinels ping master and replicas periodically.
2. Subjective down → enough Sentinels → objective down.
3. Leader Sentinel elects best replica (priority, offset).
4. REPLICAOF NO ONE on chosen replica.
5. Other replicas reconfigured to new master.

Syntax reference

Common commands

• Port 26379 default Sentinel.
• quorum 2 on 3 Sentinels.
• down-after-milliseconds — subjective failure threshold.

# sentinel.conf
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000

redis-cli -p 26379 SENTINEL masters

Informative example

Query Sentinel for current master after failover:

redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# 1) "10.0.1.55"
# 2) "6379"

redis-cli -p 26379 SENTINEL replicas mymaster

Lettuce RedisSentinelConfiguration in Spring discovers master dynamically. Hardcoding master IP breaks after failover.

Real-world use

Real-world use cases

• HA for single Redis master + replicas.
• Auto failover without human at 3am.
• Service discovery of current master.
• Staging parity with prod topology.
• Legacy apps before Cluster migration.

Best practices

• Minimum 3 Sentinels across failure domains.
• Sentinel on separate hosts from Redis data nodes.
• Client library Sentinel-aware.
• Test failover quarterly in staging.
• Set sensible down-after-milliseconds.
• Monitor Sentinel logs and +switch-master.

Common mistakes

• Single Sentinel — no quorum failover.
• All Sentinels on same VM as only master.
• Hardcoded master IP in application.
• Expecting Sentinel to shard data.

Advanced interview questions

Summary

Sentinel = automatic failover for master/replica.