Configure Redis Sentinel Quorum for Failover

Deploy three Sentinel monitors across separate nodes, set a quorum of two, and verify automatic master promotion when the primary loses contact with the majority.

~35 minredissentinelfailover

Task

Make Redis survive a single-node failure by configuring Sentinel quorum and testing promotion end-to-end.

When to use this

A single Redis master serves a cache tier with no replica, so every master restart drops the cache and spikes the database. The team wants automated failover without a managed service.

Prerequisites

Three reachable hosts with Redis 7.x installed
Network firewall allows port 26379 between all Sentinels
A test workload that reads and writes a known key

Steps

1. Start one Redis server on each host with persistence tuned for cache use.

redis-server --daemonize yes --save "" --appendonly no

Expected output: Three redis-server processes are listening on port 6379, one per host.

2. Configure the first host as master and the other two as replicas of it.

redis-cli -h replica-host REPLICAOF master-host 6379

Expected output: INFO replication on each replica shows role:slave and master_link_status:up.

3. Start a Sentinel on each host pointing at the master with quorum two and down-after 3000ms.

sentinel monitor mymaster master-host 6379 2
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 15000
sentinel parallel-syncs mymaster 1

Expected output: Each Sentinel logs +monitor for mymaster and can reach the master on port 6379.

4. Stop the master process and watch the Sentinels elect a new master.

redis-cli -h master-host SHUTDOWN NOSAVE

Expected output: Within failover-timeout, SENTINEL get-master-addr-by-name mymaster returns a different host.

Troubleshooting

Problem

Sentinels disagree on the master

Solution

Ensure every Sentinel uses the same monitor name and master address; a typo in one config splits the quorum and blocks failover.

Problem

Failover does not trigger

Solution

Check that down-after-milliseconds is shorter than the network timeout and that Sentinels can reach each other on port 26379.

Limitations

Sentinel cannot protect against a network partition that isolates the master from clients but not from Sentinels.
A simultaneous failure of two nodes leaves no quorum, so manual recovery is required.

Why quorum matters

Sentinel uses a majority vote to decide that the master is down and to promote a replica. With three Sentinels and a quorum of two, one Sentinel can fail without blocking the decision, and one network partition cannot elect two masters at once. A quorum of one on a three-node cluster gives you no split-brain protection.

Wire the replicas first

A Sentinel can only promote a replica that already replicates from the master. Configure replication before starting Sentinels so the promotion candidate has fresh data.

redis-cli -h replica-host REPLICAOF master-host 6379
redis-cli -h replica-host INFO replication

Test the failover

Kill the master process, not the network. A clean shutdown lets Sentinels observe the loss and run the promotion. Watch the Sentinel log for +sdown, +odown, +failover-abort, and finally +failover-end. After promotion, point your client at the Sentinel address instead of a fixed host so it follows the new master.

Expected outcome

SENTINEL get-master-addr-by-name returns a host that was previously a replica, the old master rejoins as a replica when it returns, and the test workload continues without a reconnect storm.