Two sentinels
Losing one leaves no majority, so failover can never be authorised
- master-name
- mymaster
- sentinels
- 2
Redis Sentinel Config Generator
Generate sentinel.conf for a monitored primary. Two things decide whether failover works, and only one of them is the quorum: performing a failover also needs a majority of all sentinels to be reachable, which is why two sentinels can never fail over.
sentinel.conf
updates as you typeExamples
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
An even number
Four buys nothing over three and makes a split vote possible
- master-name
- mymaster
- sentinels
- 4
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Running two sentinels
A majority of two is two, so losing either one makes failover impossible. Two sentinels detect an outage and can do nothing about it.
Instead:Run three, on three separate hosts.
Lowering the quorum to make failover easier
The quorum only controls agreement that the primary is down. The majority requirement for performing the failover is separate and cannot be lowered.
Instead:Add sentinels rather than lowering the quorum.
Pointing clients at the primary's address
After a promotion the client keeps writing to the old primary, which now rejects writes with READONLY.
Instead:Use the client library's Sentinel support.
Deploying sentinel.conf from configuration management on every restart
Sentinel rewrites the file to record the current primary and its peers. Overwriting it discards that state.
Instead:Template it once, then exclude it.
The quorum is not the whole story
Sentinel has two separate thresholds and configuring only the visible one is the usual reason a failover does not happen when it should.
Two sentinels can never fail over
Losing one leaves a single sentinel, which is not a majority of two, so no failover can be authorised. Three is the minimum, on three separate hosts, and an even number above that buys nothing over the odd number below it.
Clients must talk to Sentinel, not to the primary
Sentinel does not proxy traffic; it tells clients where the primary is. A client configured with the primary's host and port keeps pointing at the old primary after a promotion, and the symptom is writes failing with READONLY.
down-after-milliseconds is a trade, not a tuning knob
Too low and an ordinary garbage collection pause triggers a failover nobody wanted. Too high and a real outage lasts longer than it needs to. The right value depends on how long your primary can legitimately stall.
Sentinel rewrites its own config file
It records the current primary and the other sentinels it has discovered. Deploying the same file to every host from configuration management will overwrite that state, so exclude it after the first start.
Related redis tools
Redis Config File Generator A redis.conf with the reasons in it Redis Maxmemory Config Generator The limit, and the headroom it needs Redis Persistence Config Generator How much you can afford to lose Redis TLS Config Generator Encrypted, and the old port actually closed Redis Cluster Config Generator Three primaries, and the bus port open Redis Client Config Generator Timeouts on both sides, and a sane pool
All 53 redis tools