The Role of Sentinel
Redis Sentinel is a separate process (or set of processes) that monitors primary and replica instances, detects when the primary is unreachable, and coordinates automatic failover by promoting a replica. Sentinel does not sit in the data path — clients don't send GET/SET through Sentinel — instead, clients query Sentinel to discover which instance is currently the primary, then connect to that instance directly. A single Sentinel is a single point of failure for the monitoring layer, so Sentinel is always deployed as a quorum of at least three independent processes that agree before triggering a failover.
Cricket analogy: It's like the third umpire who doesn't play in the match but watches every ball and steps in to overturn a decision — Sentinel doesn't handle traffic, it watches and intervenes when something's wrong.
Failure Detection: Subjective and Objective Down
Each Sentinel independently pings the primary at regular intervals. If a Sentinel doesn't get a valid reply within down-after-milliseconds, it marks the primary as Subjectively Down (SDOWN) from its own point of view — this could just mean that one Sentinel has a network problem. Sentinels gossip with each other, and if a configured quorum of Sentinels agree the primary is down, it's promoted to Objectively Down (ODOWN), which is the trigger for starting a failover. This two-tier check prevents a single Sentinel's flaky network link from causing an unnecessary failover.
Cricket analogy: It's like one fielder claiming a catch was clean while the rest of the team isn't sure — only when enough players and the replay agree does the umpire officially give it out.
Sentinel Configuration
# 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
# 'mymaster' is the logical name clients use to look up the primary
# 2 is the quorum required to mark the primary as ODOWNClient Discovery and Failover Flow
Clients using Sentinel-aware libraries don't hardcode the primary's address. They ask any Sentinel 'who is the primary for mymaster right now' via SENTINEL GET-MASTER-ADDR-BY-NAME, and reconnect if that address changes. When ODOWN is reached, the Sentinels elect a leader among themselves (using a Raft-like voting protocol) to run the failover: the leader Sentinel picks the best-qualified replica (based on replication offset and priority), sends it REPLICAOF NO ONE to promote it, reconfigures the other replicas to point at the new primary, and publishes the new address so clients update their connections.
Cricket analogy: It's like a team not fixing a specific stand-in captain in advance — when the captain is injured, the selectors quickly agree on the vice-captain best positioned to lead, based on current form.
Sentinel quorum determines when a failover is *considered*, but the actual failover requires a majority of the total Sentinel processes to authorize the leader — always run an odd number of Sentinels (typically 3 or 5) spread across failure domains so a network partition can't strand you without a majority.
Sentinel can also be used purely for monitoring and alerting even if you don't want automatic failover, since it independently tracks primary/replica health and can publish notifications on state changes.
- Sentinel monitors primary/replica health and orchestrates automatic failover; it is not in the client's data path.
- Failure detection uses two tiers: SDOWN (one Sentinel's view) and ODOWN (quorum-confirmed), preventing false failovers from a single flaky link.
- Sentinel deployments require an odd number of independent processes (commonly 3+) across separate failure domains.
- Clients discover the current primary via SENTINEL GET-MASTER-ADDR-BY-NAME rather than hardcoding an address.
- A leader Sentinel is elected via quorum voting to execute the failover, choosing the best replica by offset and priority.
- failover-timeout and parallel-syncs control failover pacing and how many replicas resync simultaneously against the new primary.
- Sentinel can be used for monitoring/alerting alone, independent of enabling automatic failover.
Practice what you learned
1. What is the role of Redis Sentinel in a deployment?
2. What distinguishes SDOWN from ODOWN?
3. Why should Sentinel be deployed with an odd number of processes (e.g., 3 or 5) across failure domains?
4. How do Sentinel-aware clients find the current Redis primary?
5. During failover, how is the replacement primary chosen?
Was this page helpful?
You May Also Like
Redis Replication
How Redis copies data from a primary to one or more replicas for read scaling and failover readiness, and the consistency tradeoffs that come with it.
Redis Cluster Explained
How Redis Cluster shards data across multiple nodes using hash slots, and how it handles failover and multi-key operations.
Redis Persistence Tradeoffs
A practical comparison of RDB snapshots and AOF logging in Redis, and how to choose or combine them based on your durability and performance needs.