Understanding Redis Sentinel: Architecture, Configuration, and Automatic Failover

Redis Sentinel is a high‑availability solution that adds monitoring, notification, and automatic failover capabilities to a Redis deployment, allowing a master‑slave cluster to continue serving requests when the master fails.

Sentinel architecture consists of sentinel nodes (special Redis instances that do not store data) and data nodes (master and replicas). Sentinels continuously ping masters and replicas, publish their status via the __sentinel__:hello channel, and can notify clients of topology changes.

Configuration of master and replicas uses standard redis.conf files. Example configurations:

#redis.conf  master
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"

#redis_6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
replicaof 127.0.0.1 6379

#redis_6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
replicaof 127.0.0.1 6379

These instances are started with:

redis-server redis.conf
redis-server redis_6380.conf 
redis-server redis_6381.conf

After launching, redis-cli can verify replication status:

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=154,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=140,lag=1

Sentinel node configuration is similar, differing only in port and the sentinel monitor line:

# redis-sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 127.0.0.1 6379 2

# redis-sentinel-26380.conf
port 26380
daemonize yes
logfile "26380.log"
sentinel monitor mymaster 127.0.0.1 6379 2

# redis-sentinel-26381.conf
port 26381
daemonize yes
logfile "26381.log"
sentinel monitor mymaster 127.0.0.1 6379 2

Sentinels are started with:

redis-sentinel redis-sentinel-26379.conf
redis-sentinel redis-sentinel-26380.conf
redis-server redis-sentinel-26381.conf --sentinel   # equivalent to redis-sentinel redis-sentinel-26381.conf

Running redis-cli -p 26380 info sentinel shows that the sentinel is monitoring the master:

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

When the master is killed, sentinels detect the outage, reach a consensus (subjective then objective down), elect a leader using the Raft algorithm, and perform a three‑step failover: select a healthy replica, promote it with slaveof no one, reconfigure other replicas with slaveof, and finally turn the old master into a replica.

Sentinels also use Pub/Sub to discover each other and to inform clients. Clients can subscribe to sentinel events, for example: SUBSCRIBE +odown or to all events: PSUBSCRIBE * The article concludes that Redis Sentinel provides three core functions—monitoring, leader election, and notification—making it a reliable high‑availability layer for Redis clusters.