Why Redis Sentinel?

Redis is an in-memory data store used for caching, session management, message brokering, and real-time analytics. In production, a single Redis instance is a single point of failure — if it goes down, your application loses access to all cached data.

Redis Sentinel solves this by providing:

  • Monitoring: Continuously checks that master and replica instances are working.
  • Automatic failover: When a master fails, Sentinel automatically promotes a replica to master.
  • Configuration provider: Clients query Sentinel to discover the current master address.
  • Notification: Sends alerts via pub/sub when topology changes occur.

Prerequisites

  • Three Linux servers (for Redis master + 2 replicas with co-located Sentinels).
  • Redis 7.0+ installed on all nodes.
  • Network connectivity between all servers on ports 6379 (Redis) and 26379 (Sentinel).
  • Root or sudo access.

Step-by-Step Setup

1. Configure Redis Master

On Server 1 (192.168.1.101), edit /etc/redis/redis.conf:

bind 0.0.0.0
port 6379
protected-mode no
requirepass "your-strong-password"
masterauth "your-strong-password"

# Persistence
appendonly yes
appendfsync everysec

2. Configure Redis Replicas

On Server 2 (192.168.1.102) and Server 3 (192.168.1.103):

bind 0.0.0.0
port 6379
protected-mode no
requirepass "your-strong-password"
masterauth "your-strong-password"

replicaof 192.168.1.101 6379

# Persistence
appendonly yes
appendfsync everysec

Start Redis on all three servers:

sudo systemctl start redis-server
sudo systemctl enable redis-server

Verify replication:

redis-cli -a "your-strong-password" INFO replication

3. Configure Sentinel on All Three Nodes

Create /etc/redis/sentinel.conf on each server:

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
dir /var/lib/redis

sentinel monitor mymaster 192.168.1.101 6379 2
sentinel auth-pass mymaster your-strong-password
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Key settings explained:

  • sentinel monitor mymaster ... 2: Monitor the master named “mymaster” with a quorum of 2 (2 out of 3 Sentinels must agree the master is down).
  • down-after-milliseconds 5000: Mark the master as subjectively down after 5 seconds of no response.
  • failover-timeout 60000: Maximum time (60s) for the failover process.
  • parallel-syncs 1: Only 1 replica re-syncs at a time after failover (reduces load).

4. Start Sentinel and Verify

sudo redis-sentinel /etc/redis/sentinel.conf

# Check Sentinel status
redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster

5. Test Failover

# Stop the master
sudo systemctl stop redis-server   # On Server 1

# Watch Sentinel logs
sudo tail -f /var/log/redis/sentinel.log

# After ~5 seconds, check the new master
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

Troubleshooting

Sentinel Won’t Trigger Failover

  1. Quorum not met: If too many Sentinels are down, the remaining ones can’t reach quorum. Check with SENTINEL ckquorum mymaster.
  2. down-after-milliseconds too high: Default is 30 seconds. Lower to 5000ms for faster detection.
  3. Network partition: The master is reachable from some Sentinels but not others. Check firewall and network rules.

Split-Brain: Two Masters Simultaneously

This occurs when a network partition causes separate groups of Sentinels to elect different masters:

# Prevent stale master from accepting writes during partition
min-replicas-to-write 1
min-replicas-max-lag 10

This makes Redis reject writes if no replica has acknowledged data within the last 10 seconds.

Client Not Reconnecting After Failover

Applications must use a Sentinel-aware client that automatically discovers the new master:

# Python example with redis-py
from redis.sentinel import Sentinel

sentinel = Sentinel([
    ('192.168.1.101', 26379),
    ('192.168.1.102', 26379),
    ('192.168.1.103', 26379)
], socket_timeout=0.5)

master = sentinel.master_for('mymaster', password='your-strong-password')
master.set('key', 'value')

Replica Promotion Selects Wrong Node

Control which replica gets promoted by setting replica-priority:

# On the preferred failover candidate (lower = preferred)
replica-priority 10

# On the less-preferred replica
replica-priority 100

# Set to 0 to prevent a replica from ever being promoted
replica-priority 0

Gotchas

  • Sentinel rewrites its config file: Never edit sentinel.conf while Sentinel is running — it auto-updates the file with discovered topology.
  • Password synchronization: requirepass and masterauth must be identical on all nodes (master and replicas). Sentinel needs sentinel auth-pass to connect.
  • Sentinel is not a proxy: Clients must connect to Sentinel first to discover the master, then connect to Redis directly. Sentinel does not forward commands.

Summary

  • Redis Sentinel provides automatic failover, monitoring, and service discovery for Redis deployments.
  • Deploy at least 3 Sentinel instances with a quorum of 2 for fault tolerance.
  • Use min-replicas-to-write to prevent split-brain data loss.
  • Applications must use Sentinel-aware clients to handle failover transparently.