Build a Highly Available Redis Sentinel Cluster: 1 Master, 2 Slaves, 3 Sentinels

Overview

The article provides a complete walkthrough for building a Redis Sentinel high‑availability architecture consisting of one master node, two replica nodes, and three sentinel monitors, covering architecture, installation, configuration, startup, validation, client usage, failover testing, and best‑practice notes.

Architecture

The cluster includes:

Data nodes : 1 master (port 6379) and 2 replicas (ports 6380, 6381).

Sentinel nodes : 3 sentinels (ports 26379, 26380, 26381) that monitor the master and perform automatic failover.

Application side : Clients obtain the current master address from the sentinels instead of hard‑coding IP/port.

Environment Preparation

Recommended: three separate physical or virtual machines for Redis and sentinel processes.

Demo: single machine with multiple ports (used in this guide).

All servers must keep time synchronized (e.g., NTP).

Install Redis

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install redis-server

# Or build from source
wget http://download.redis.io/redis-stable.tar.gz
tar xzf redis-stable.tar.gz
cd redis-stable
make

Configure Master and Replicas

Master (redis-6379.conf)

port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis_6379.log"
dir /var/redis/6379
requirepass your_strong_password
masterauth your_strong_password

Replica 1 (redis-6380.conf)

port 6380
daemonize yes
pidfile /var/run/redis_6380.pid
logfile "/var/log/redis_6380.log"
dir /var/redis/6380
slaveof 127.0.0.1 6379
requirepass your_strong_password
masterauth your_strong_password

Replica 2 (redis-6381.conf)

port 6381
daemonize yes
pidfile /var/run/redis_6381.pid
logfile "/var/log/redis_6381.log"
dir /var/redis/6381
slaveof 127.0.0.1 6379
requirepass your_strong_password
masterauth your_strong_password

Configure Sentinel

Sentinel 1 (sentinel-26379.conf)

port 26379
daemonize yes
pidfile /var/run/redis-sentinel_26379.pid
logfile "/var/log/redis/sentinel_26379.log"
dir /tmp

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster your_strong_password
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

Sentinel 2 and Sentinel 3 use the same configuration, only the port value changes to 26380 and 26381 respectively.

Start Services

# Start Redis master and replicas
redis-server /path/to/redis-6379.conf
redis-server /path/to/redis-6380.conf
redis-server /path/to/redis-6381.conf

# Start sentinel processes
redis-sentinel /path/to/sentinel-26379.conf
redis-sentinel /path/to/sentinel-26380.conf
redis-sentinel /path/to/sentinel-26381.conf

Validate the Cluster

# Check replication status
redis-cli -p 6379 info replication

# View sentinel monitoring info
redis-cli -p 26379 info sentinel
redis-cli -p 26379 sentinel masters
redis-cli -p 26379 sentinel slaves mymaster

Client Connection Example (Python)

import redis
from redis.sentinel import Sentinel

# Connect to the sentinel cluster
sentinel = Sentinel([
    ('localhost', 26379),
    ('localhost', 26380),
    ('localhost', 26381)
], socket_timeout=0.1)

# Get a connection to the master for writes
master = sentinel.master_for('mymaster', password='your_strong_password', socket_timeout=0.1)
master.set('foo', 'bar')

# Get a connection to a replica for reads
slave = sentinel.slave_for('mymaster', password='your_strong_password', socket_timeout=0.1)
print(slave.get('foo'))

Failover Test

# 1. Stop the master node
redis-cli -p 6379 shutdown

# 2. Wait ~30 seconds (depends on down‑after‑milliseconds)

# 3. Verify that sentinel performed failover
redis-cli -p 26379 sentinel masters

Precautions

In production, deploy sentinel and Redis nodes on separate machines.

Synchronize system clocks using NTP to avoid drift.

Enable authentication (requirepass) and restrict firewall access to application servers only.

Monitor Redis and sentinel logs regularly.

Periodically run failover drills to ensure the setup works under real failures.

Troubleshooting

Master‑replica sync fails – Verify that masterauth and requirepass are identical on both sides.

Sentinel does not trigger failover – Ensure the IP address in sentinel monitor is reachable; in production use an internal network IP.

Client write errors – Confirm the application obtains the master address from sentinel instead of hard‑coding the old master.

Following these steps results in a fully functional Redis Sentinel high‑availability cluster with one master, two replicas, and three sentinel monitors.