Database / REDIS
What happens when a Redis master fails in a Sentinel-managed setup?
Sentinel's failover process follows a defined sequence rather than reacting instantly to any single missed check, specifically to avoid triggering an unnecessary failover from a brief, isolated network blip.
flowchart TD
A[Sentinel loses contact with master] --> B[Master marked SDOWN, subjectively down, by that one Sentinel]
B --> C[Sentinel asks other Sentinels for their view of the master]
C --> D{Quorum of Sentinels agree master is down?}
D -- No --> E[No failover; likely a local network issue for one Sentinel]
D -- Yes --> F[Master marked ODOWN, objectively down]
F --> G[Sentinels elect a leader Sentinel to run the failover]
G --> H[Leader Sentinel selects the best-positioned replica, e.g. most up-to-date]
H --> I[Selected replica promoted to master via REPLICAOF NO ONE]
I --> J[Other replicas reconfigured to replicate from the new master]
J --> K[Sentinels update their config and notify connected clients of the new master]
Clients using a Sentinel-aware library discover the new master by asking Sentinel for the current address rather than hardcoding a fixed host, which is what lets an application keep working through a failover without a manual configuration change. Any writes made to the old master that hadn't yet replicated to the promoted replica at the moment of failure are lost, since Sentinel can't recover data the new master never received.
Why does Sentinel require quorum agreement before declaring a master objectively down (ODOWN)?
What data can be lost during a Sentinel-managed failover?
More Related questions...
