How to Configure Redis Sentinel for High-Availability In-Memory Caching on Linux

Why Standalone Redis Is a Single Point of Failure

Redis is widely deployed across production web infrastructure to handle session state, database query caching, rate limiting, and background job queues. However, running a standalone Redis server creates a dangerous single point of failure (SPOF). If the Redis server crashes or experiences hardware failure, all dependent web applications immediately suffer from cache stampedes, session disconnects, and database overloads.

Redis Sentinel is the official distributed high-availability monitoring system for Redis. Sentinel continuously monitors master and replica instances, verifies consensus through distributed quorum voting, automatically promotes a healthy replica to master upon failure, and dynamically updates client applications with new connection endpoints—delivering continuous zero-downtime caching.

In this high-availability infrastructure guide, we will configure a resilient Redis master-replica topology on Ubuntu 24.04/22.04 LTS, deploy 3 Sentinel monitoring daemons with quorum consensus, and test simulated failover recovery.

Step 1: Installing Redis Server and Sentinel on Nodes

Install Redis server and sentinel packages across your primary master and replica instances:

# Install Redis server and sentinel
sudo apt update && sudo apt install -y redis-server redis-sentinel

# Stop services to apply initial configuration
sudo systemctl stop redis-server redis-sentinel

Step 2: Configuring Redis Master Node (10.0.0.1)

Edit /etc/redis/redis.conf on the Master server:

# Bind to internal private IP
bind 127.0.0.1 10.0.0.1
port 6379

# Enforce secure authentication password
requirepass "UltraStrongClusterSecret2026!"
masterauth "UltraStrongClusterSecret2026!"

# Memory limit & eviction policy
maxmemory 512mb
maxmemory-policy allkeys-lru

Start Redis Master: sudo systemctl start redis-server.

Step 3: Configuring Redis Replica Node (10.0.0.2)

Edit /etc/redis/redis.conf on the Replica server to mirror the master:

bind 127.0.0.1 10.0.0.2
port 6379

requirepass "UltraStrongClusterSecret2026!"
masterauth "UltraStrongClusterSecret2026!"

# Declare Master upstream replication target
replicaof 10.0.0.1 6379

Start Redis Replica: sudo systemctl start redis-server.

Step 4: Configuring Redis Sentinel Daemons (Quorum 2)

On all 3 nodes (or Sentinel monitoring nodes), configure /etc/redis/sentinel.conf:

# Sentinel Listening Port
port 26379
bind 0.0.0.0

# Sentinel Working Directory
dir "/var/lib/redis"

# Monitor Master Node:    
sentinel monitor mymaster 10.0.0.1 6379 2
sentinel auth-pass mymaster "UltraStrongClusterSecret2026!"

# Failover Timeouts
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 6000
sentinel parallel-syncs mymaster 1

Enable and start the Sentinel services across all nodes:

sudo systemctl enable --now redis-sentinel
sudo redis-cli -p 26379 sentinel master mymaster

Step 5: Testing Simulated Automatic Master Failover

Simulate a catastrophic hardware crash by freezing the active Redis Master:

# On Master: Force crash / pause for 30 seconds
redis-cli -a "UltraStrongClusterSecret2026!" DEBUG sleep 30

# On Sentinel Node: Watch automatic promotion happen in under 4 seconds!
redis-cli -p 26379 sentinel master mymaster

Sentinel detects the timeout, achieves quorum consensus, and automatically promotes the replica node to active master without human intervention!

Redis Sentinel Architecture Matrix

Component	Port	Role & Responsibility
Redis Master	6379	Active read/write memory data store
Redis Replica	6379	Asynchronous read-only mirror ready for promotion
Sentinel Quorum (x3)	26379	Health monitoring, leader election, automatic failover

Configuring Client Applications (PHP, Node.js, Python) for Sentinel

To benefit from automatic failover, client applications must connect to the Sentinel pool (port 26379) rather than hardcoding a single master IP address:

// PHP Predis Sentinel Connection Example
$sentinels = ['tcp://10.0.0.1:26379', 'tcp://10.0.0.2:26379', 'tcp://10.0.0.3:26379'];
$options   = [
    'replication' => 'sentinel',
    'service'     => 'mymaster',
    'parameters'  => ['password' => 'UltraStrongClusterSecret2026!']
];
$client = new Predis\Client($sentinels, $options);
$client->set('cluster_status', 'High Availability Active');

Preventing Split-Brain Scenarios with min-replicas-to-write

In the event of a network partition, prevent isolated masters from accepting writes that would later be lost during resynchronization by enforcing minimum replica acknowledgments in /etc/redis/redis.conf:

# Require at least 1 healthy replica acknowledged within 10 seconds before accepting writes
min-replicas-to-write 1
min-replicas-max-lag 10

Redis Sentinel Diagnostic Commands

• redis-cli -p 26379 sentinel masters: Display status of all monitored master nodes.
• redis-cli -p 26379 sentinel ckquorum mymaster: Check if Sentinel quorum is healthy.

Configuring Sentinel Notification Scripts & Discord Webhooks

Sentinel can trigger custom shell scripts whenever operational state changes occur (such as warnings, master down transitions, or successful failovers):

# Add notification script directive in /etc/redis/sentinel.conf
sentinel notification-script mymaster /var/lib/redis/sentinel-notify.sh
sentinel client-reconfig-script mymaster /var/lib/redis/sentinel-reconfig.sh

Create notification script /var/lib/redis/sentinel-notify.sh:

#!/bin/bash
EVENT_TYPE=$1
EVENT_DESC=$2

# Post instant alert payload to Discord / Slack webhook
curl -H "Content-Type: application/json" -X POST   -d "{"content": "⚠️ [Redis Sentinel Alert] $EVENT_TYPE: $EVENT_DESC"}"   https://discord.com/api/webhooks/YOUR_WEBHOOK_URL

Monitoring Sentinel Consensus in Production

Inspect real-time Sentinel consensus metrics and connected replica health with redis-cli -p 26379 info sentinel to ensure high-availability quorum is always satisfied.

Production Checklist for Enterprise Redis Sentinel High Availability

• Enforce Odd Number of Sentinels: Always run at least 3 Sentinel instances across distinct physical failure domains to prevent split-brain voting ties.
• Tune failover-timeout: Set sentinel failover-timeout to 6000ms (6 seconds) for fast automated promotion without triggering false alarms during transient network blips.
• Enable Memory Overcommit in Linux Kernel: Set vm.overcommit_memory = 1 in /etc/sysctl.conf on all Redis nodes.