Redis Sentinel
Redis Sentinel watches your Redis servers and repairs the setup when the main server fails. It detects the failure, promotes a replica to the new main server, and tells your applications where to connect. Sentinel gives a replicated Redis setup automatic high availability without a full Cluster.
The Night Guard Analogy
A building has one manager and two assistants. Three night guards watch the manager's office. When the manager disappears, the guards compare notes. If most of them agree the manager is gone, they appoint one assistant as the new manager and tell all visitors. Sentinel guards perform exactly this job for Redis.
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Sentinel 1 │ │ Sentinel 2 │ │ Sentinel 3 │
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘
│ watch │ watch │ watch
▼ ▼ ▼
┌──────────────────────────────────────────┐
│ Redis Main (master) │
└──────────────┬─────────────┬─────────────┘
│ copies │ copies
┌─────▼─────┐ ┌─────▼─────┐
│ Replica 1 │ │ Replica 2 │
└───────────┘ └───────────┘
What Sentinel Does
- Monitoring: checks every few seconds that main and replica servers respond.
- Notification: alerts administrators or scripts when something breaks.
- Automatic failover: promotes a replica when the main server fails.
- Configuration provider: tells clients the address of the current main server.
Subjectively Down and Objectively Down
One Sentinel can misjudge a failure because of a local network hiccup. Sentinel uses two states to avoid false alarms.
Sentinel 1 cannot reach main → marks it SDOWN (subjectively down)
Sentinel 2 cannot reach main → agrees
Sentinel 3 cannot reach main → agrees
Agreement reaches the quorum → main becomes ODOWN (objectively down)
Failover begins
The quorum is the number of Sentinels that must agree. With three Sentinels, a quorum of 2 works well.
The Failover Steps
1. Sentinels confirm the main server is down (ODOWN). 2. Sentinels elect one leader among themselves. 3. The leader picks the healthiest replica. 4. The leader promotes that replica to main. 5. Other replicas start copying from the new main. 6. Sentinels announce the new address to clients. 7. The old main rejoins later as a replica.
A Basic sentinel.conf
port 26379 sentinel monitor mymaster 10.0.0.5 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1
The first line tells Sentinel to watch a main server named mymaster at 10.0.0.5 and to require a quorum of 2. Down-after-milliseconds sets how long silence must last before Sentinel suspects a failure.
Start a Sentinel with this command.
$ redis-sentinel /etc/redis/sentinel.conf
Asking Sentinel for the Main Address
$ redis-cli -p 26379 127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster 1) "10.0.0.5" 2) "6379"
Sentinel-aware client libraries run this query for you. They ask any Sentinel for the current main server and reconnect on their own after a failover.
Useful Sentinel Commands
SENTINEL masters → lists watched main servers SENTINEL replicas mymaster → lists replicas of mymaster SENTINEL sentinels mymaster → lists other Sentinels SENTINEL failover mymaster → forces a manual failover
Practical Example – Surviving a Server Crash
09:00 Main server at 10.0.0.5 serves the shop.
09:15 The server loses power.
09:15 Sentinels notice no reply for 5 seconds.
09:15 All three agree: ODOWN.
09:16 Replica at 10.0.0.6 becomes the new main.
09:16 Shop clients reconnect to 10.0.0.6.
Orders continue with a short pause.
Design Rules
- Run at least three Sentinels on separate machines.
- Keep the Sentinel count odd so a majority always exists.
- Replication is asynchronous, so a failover can lose the last few writes.
- Sentinel does not split data across servers. Use Redis Cluster for sharding.
Key Points
- Sentinel monitors, alerts, fails over, and informs clients.
- A quorum of Sentinels must agree before a failover starts.
- Clients ask Sentinel for the current main address.
- Three Sentinels on separate hosts form the minimum safe setup.