Monitor Redis with Sentinel

You've built applications that rely on Redis for caching, sessions, or real-time data — and you've probably woken up at 3 AM to a dead Redis master. Without automatic failover, a single Redis node becomes a single point of failure that can take down your entire stack. This lesson shows you how to configure Redis Sentinel to monitor your Redis instances and perform automatic failover, turning chaos into resilience.

The problem this lesson solves

A single Redis server works great in development, but in production it's vulnerable. If the master crashes, writes are lost, and every client gets connection errors. Manual failover is slow, error-prone, and requires SSH access. Meanwhile, your users experience downtime.

Redis Sentinel solves this by running a separate process (or cluster of processes) that: - Monitors your Redis master and replicas for health. - Automatically detects when the master is down (using a quorum of sentinels). - Promotes a replica to master and reconfigures the rest. - Tells clients where the new master is (via pub/sub or the SENTINEL get-master-addr-by-name command).

Without Sentinel, scaling with replicas gives you read capacity but no automatic recovery. With Sentinel, you get high availability — the system heals itself without human intervention.

Core concept / mental model

Think of Redis Sentinel as a distributed watchdog for your Redis deployments. Key roles:

• Master: the primary Redis node accepting writes.
• Replica: copies data from the master; can be promoted if master fails.
• Sentinel: an independent process that talks to other sentinels and Redis nodes to make decisions.

Quorum is the minimum number of sentinels that must agree a master is down before failover begins. For example, with 3 sentinels, you might set quorum to 2.

How failover works (mental model)

1. Sentinels ping the master every second (by default).
2. If one sentinel doesn't get a reply within down-after-milliseconds, it marks the master as sdown (subjectively down).
3. That sentinel asks other sentinels: "Is the master down?"
4. If enough sentinels agree (>= quorum), the master is marked odown (objectively down).
5. Sentinel leader is elected, and it picks a replica to promote.
6. All other replicas are reconfigured to follow the new master.

Pro tip: Always run an odd number of sentinels (at least 3) to avoid split-brain scenarios.

How it works step by step

Step 1: Prepare your Redis instances

You need one master and at least one replica. For testing, you can run them on different ports locally.

Master config (redis-master.conf):

port 6379
bind 0.0.0.0
daemonize no
logfile ""

Replica config (redis-replica.conf):

port 6380
bind 0.0.0.0
daemonize no
logfile ""
slaveof 127.0.0.1 6379

In Redis 5+, use replicaof instead of slaveof.

Step 2: Configure Sentinel

Create a sentinel config file (e.g., sentinel.conf) for each sentinel process:

port 26379
daemonize no
logfile ""
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Key directives: - sentinel monitor mymaster 127.0.0.1 6379 2 — monitors the master named "mymaster" on port 6379 with quorum 2. - down-after-milliseconds — how long without ping response before considering it down. - failover-timeout — time to complete failover before giving up. - parallel-syncs — number of replicas to sync simultaneously after promotion.

Step 3: Start processes

Start the master, replica, and at least 3 sentinels (on different ports or machines).

redis-server redis-master.conf &
redis-server redis-replica.conf &
redis-sentinel sentinel1.conf &

For multiple sentinels, create separate configs with different ports (26379, 26380, 26381) and data directories.

Step 4: Test failover

Simulate a master crash:

redis-cli -p 6379 DEBUG SLEEP 30

Or kill the master process. After 5 seconds, Sentinel will detect the failure. Check the status:

redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

Output will show the new master's IP and port (e.g., 127.0.0.1 and 6380).

Hands-on walkthrough

Let's set up a complete 3-node Sentinel cluster with one master and two replicas.

Step 1: Create directory structure

mkdir sentinel-lab && cd sentinel-lab

Step 2: Generate config files

Master (port 6379):

port 6379
daemonize no
logfile ""
save ""
appendonly no

Replica 1 (port 6380):

port 6380
daemonize no
logfile ""
replicaof 127.0.0.1 6379
save ""
appendonly no

Replica 2 (port 6381):

port 6381
daemonize no
logfile ""
replicaof 127.0.0.1 6379
save ""
appendonly no

Sentinel 1 (port 26379):

port 26379
daemonize no
logfile ""
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Sentinel 2 (port 26380): same but with port 26380 and sentinel monitor mymaster 127.0.0.1 6379 2.

Sentinel 3 (port 26381): same pattern.

Step 3: Launch everything

redis-server master.conf &
redis-server replica1.conf &
redis-server replica2.conf &
redis-sentinel sentinel1.conf &
redis-sentinel sentinel2.conf &
redis-sentinel sentinel3.conf &

Step 4: Verify the setup

redis-cli -p 26379 SENTINEL masters

Expected output (truncated):

1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "..."
    9) "flags"
   10) "master"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "..."
   19) "last-ping-reply"
   20) "..."
   21) "down-after-milliseconds"
   22) "5000"
   23) "info-refresh"
   24) "..."
   25) "role-reported"
   26) "master"
   27) "role-reported-time"
   28) "..."
   29) "config-epoch"
   30) "0"
   31) "num-slaves"
   32) "2"
   33) "num-other-sentinels"
   34) "2"
   35) "quorum"
   36) "2"
   37) "failover-timeout"
   38) "60000"
   39) "parallel-syncs"
   40) "1"

Step 5: Trigger failover

Kill the master process or simulate a pause:

redis-cli -p 6379 DEBUG SLEEP 30 &
sleep 6
echo "Checking new master..."
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

Expected output: 127.0.0.1 and 6380 (or 6381).

Step 6: Verify client reconnection

Your application code should use Sentinel to discover the master:

import redis
from redis.sentinel import Sentinel

sentinel = Sentinel([('127.0.0.1', 26379), ('127.0.0.1', 26380), ('127.0.0.1', 26381)],
                    socket_timeout=0.1)
master = sentinel.master_for('mymaster', socket_timeout=0.1)
print(master.set('key', 'value'))  # True

slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
print(slave.get('key'))  # b'value'

Compare options / when to choose what

When to choose Sentinel:

• You need automatic failover but don't need data sharding.
• You have a small to medium dataset (fits on one node).
• You want simple operations and monitoring.

When to choose Redis Cluster:

• Dataset exceeds single-node memory.
• Need automatic sharding and high throughput.
• You're okay with more complex client libraries.

Troubleshooting & edge cases

Common problems and fixes

Split-brain scenario: Two sentinel groups promote different masters. Fix: run an odd number of sentinels (≥3) and set quorum to N/2 + 1.

Failover never triggers: Check that all sentinels can reach the master and each other. Use SENTINEL ckquorum mymaster to verify quorum.

Replica not syncing after failover: Ensure replicaof directive is removed from promoted replica (Sentinel handles this automatically). Check logs with redis-cli -p 6380 ROLE.

Client connection errors: Your app must reconnect after failover. Use Sentinel-aware client libraries (e.g., redis-py with Sentinel class).

Pro tip: Always test failover in a staging environment. Use SENTINEL FAILOVER mymaster to manually trigger a failover for testing.

What you learned & what's next

You now understand how to monitor Redis with Sentinel — from configuration to automatic failover. You learned: - Sentinel's role as a distributed watchdog. - How to set up a Sentinel cluster with quorum. - How to test failover and handle edge cases.

Next lesson: Dive into Redis Cluster for automatic sharding across multiple nodes. This builds on Sentinel by adding data distribution — essential for scaling beyond a single node's memory.

Master these concepts, and your Redis infrastructure will survive failures without waking you up at 3 AM.