Redis Sentinel: How Automatic Failover Actually Works
How Redis Sentinel provides high availability: quorum-based monitoring, master election, automatic failover, and what your client applications must do to follow along.
· 2 min read
A single Redis instance is a single point of failure. Sentinel is Redis’s own answer to that: a distributed set of monitor processes that watch your Redis servers and promote a replica when the master dies, without a human in the loop. Here is the shape of it.
The moving parts
- Sentinel instances. You deploy at least three, so they can form a quorum and no single Sentinel failure takes down the monitoring itself.
- One master. All writes go to it. Everything else replicates from it.
- Replicas. They serve reads and stand by as failover candidates.
What Sentinel does
The Sentinel processes continuously ping the master and its replicas. When the master stops responding for longer than the configured down-after-milliseconds, the Sentinels compare notes. Only when enough of them agree the master is down (the quorum) does a failover begin. That agreement step matters: it stops one Sentinel with a flaky network path from triggering an unnecessary failover.
The failover itself:
- The Sentinels elect a new master from the healthy replicas, based on replication offset and configured priorities.
- The remaining replicas are reconfigured to replicate from the new master.
- Sentinel publishes the new topology so clients can redirect their writes.
The part people forget: the client
Failover on the server side is only half the story. Your application cannot simply hold a connection to a fixed master address, because that address stops being the master. Sentinel-aware clients connect to the Sentinels first, ask “who is the master for this name”, and re-ask after a disconnection. If your Redis library is not configured for Sentinel, you have high availability on the server and an outage in the app.
When it is worth it
Sentinel earns its operational overhead when losing write capability for more than a few seconds is unacceptable. For a cache that can be cold-started, it is usually overkill. For Sidekiq queues or anything holding data you cannot regenerate, automatic failover is the difference between a blip and a paged human at 3am.