Redis Sentinel provides automatic failover and monitoring for Redis — if your primary Redis instance fails, Sentinel automatically promotes a replica, keeping your application's caching/session layer available.
What Sentinel Solves
A standalone Redis instance is a single point of failure — Sentinel monitors your Redis primary/replica setup, automatically handling failover if the primary becomes unavailable, and notifies your application of the new primary's location.
Prerequisites
- At least 3 servers (recommended for proper quorum): a Redis primary, at least one replica, and Sentinel instances (typically run alongside each Redis instance)
- Redis already installed on each (see How to Install and Secure Redis on Ubuntu & Debian)
Step 1 — Set Up Redis Replication
On each replica server:
sudo nano /etc/redis/redis.confreplicaof PRIMARY_SERVER_IP 6379sudo systemctl restart redis-serverStep 2 — Verify Replication
redis-cli -h REPLICA_IP INFO replicationShould show role:slave and successful connection to the primary.
Step 3 — Configure Sentinel
sudo nano /etc/redis/sentinel.confport 26379
sentinel monitor mymaster PRIMARY_SERVER_IP 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000The 2 in the monitor line is the quorum — the minimum number of Sentinels that must agree the primary is down before triggering failover.
Step 4 — Start Sentinel on Each Server
sudo systemctl start redis-sentinelStep 5 — Verify Sentinel Status
redis-cli -p 26379 SENTINEL mastersConnecting Your Application via Sentinel
Rather than hardcoding your Redis primary's address, configure your application's Redis client to connect through Sentinel — most mature Redis client libraries support Sentinel-aware connections, automatically discovering the current primary and handling failover transparently.
Testing Automatic Failover
Stop the current primary Redis instance (in a controlled test) and verify Sentinel detects the failure and promotes a replica within the configured timeout — confirm your application reconnects correctly to the new primary.
Understanding Quorum Requirements
With 3 Sentinel instances and a quorum of 2, at least 2 Sentinels must agree the primary is unreachable before failover triggers — prevents a single Sentinel's own network issue from triggering an unnecessary failover.
Sentinel vs Redis Cluster
Sentinel provides high availability for a single logical dataset (primary + replicas); Redis Cluster additionally provides horizontal sharding across multiple primary nodes for genuinely large datasets — choose Sentinel for HA without the need for sharding, Cluster if you also need to scale beyond a single node's capacity.
Common Errors
Failover doesn't trigger despite primary being down — verify quorum requirements are actually met (enough Sentinels can independently confirm the primary is unreachable), and check Sentinel logs for the specific reason failover didn't proceed.
Continue Reading
- How to Install and Secure Redis on Ubuntu & Debian
- How to Set Up a Read Replica for Scaling Database Reads
- How to Set Up an On-Call Rotation and Alerting Escalation Policy
Browse more articles in Databases.
