Redis Sentinel — High Availability dla Redis

Opublikowano: 10 kwietnia 2026 · Kategoria: VPS / Cache

Pojedynczy serwer Redis to punkt awarii. Jeśli pada, pada cache — a za nim często cała aplikacja. Redis Sentinel to wbudowany system High Availability: utrzymuje zestaw master + repliki, monitoruje ich stan i automatycznie awansuje replikę na mastera gdy ten padnie. Klienty są powiadamiane o nowym masterze i przełączają się bez ręcznej interwencji. Ten artykuł pokazuje jak postawić trzy-węzłowy klaster Sentinel od zera, skonfigurować klienty PHP i Node.js oraz monitorować stan klastra.

Architektura Redis Sentinel

Minimalna konfiguracja produkcyjna: 3 serwery, każdy uruchamia instancję Redis (master lub replica) oraz proces sentinel. Sentinel monitoruje Redis i zarządza failoverem przez protokół Raft-like consensus.

• Serwer A — Redis master (port 6379) + Sentinel (port 26379)
• Serwer B — Redis replica (port 6379) + Sentinel (port 26379)
• Serwer C — Redis replica (port 6379) + Sentinel (port 26379)

Krok 1 — Konfiguracja Redis master i replica

# Instalacja (Ubuntu/Debian)
sudo apt update && sudo apt install redis-server -y

# --- /etc/redis/redis.conf na MASTERZE (Serwer A) ---
bind 0.0.0.0
port 6379
requirepass "MojeHasloRedis2026"
masterauth "MojeHasloRedis2026"

# Persistencja
save 900 1
save 300 10
appendonly yes
appendfsync everysec

# --- /etc/redis/redis.conf na REPLIKACH (Serwer B i C) ---
bind 0.0.0.0
port 6379
requirepass "MojeHasloRedis2026"
masterauth "MojeHasloRedis2026"

# Wskazanie mastera (IP Serwera A)
replicaof 10.0.0.1 6379

# Replika tylko do odczytu
replica-read-only yes

# Restart na obu serwerach
sudo systemctl restart redis-server

# Weryfikacja replikacji (na replice)
redis-cli -h 10.0.0.2 -a "MojeHasloRedis2026" info replication
# Powinno pokazac: role:slave, master_link_status:up

Krok 2 — Konfiguracja sentinel.conf

Ten sam plik sentinel.conf na wszystkich 3 serwerach (różni się tylko adresem bind i announce-ip). Sentinel automatycznie odkrywa repliki przez mastera.

# /etc/redis/sentinel.conf (na KAZDYM serwerze)

port 26379
bind 0.0.0.0

# Katalog roboczy (sentinel zapisuje tu zaktualizowany config)
dir /var/lib/redis

# Monitorowanie mastera
# sentinel monitor <nazwa> <ip-mastera> <port> <quorum>
sentinel monitor mymaster 10.0.0.1 6379 2

# Haslo do Redis (wymagane jesli ustawiles requirepass)
sentinel auth-pass mymaster MojeHasloRedis2026

# Czas bez odpowiedzi po ktorym master uznany za "subiektywnie martwy" (ms)
sentinel down-after-milliseconds mymaster 5000

# Ile replik jednoczesnie moze byc rekonfigurowanych po failover
sentinel parallel-syncs mymaster 1

# Timeout failover (ms)
sentinel failover-timeout mymaster 10000

# Ogloszone IP tego sentinela (wazne za NAT/Docker)
sentinel announce-ip 10.0.0.1  # zmien na IP tego serwera
sentinel announce-port 26379

# Logowanie
logfile /var/log/redis/sentinel.log
loglevel notice

# Uruchom sentinel na wszystkich 3 serwerach
sudo redis-sentinel /etc/redis/sentinel.conf --daemonize yes

# Lub jako systemd service — /etc/systemd/system/redis-sentinel.service
# [Unit]
# Description=Redis Sentinel
# After=network.target
# [Service]
# ExecStart=/usr/bin/redis-sentinel /etc/redis/sentinel.conf
# [Install]
# WantedBy=multi-user.target

sudo systemctl enable redis-sentinel
sudo systemctl start redis-sentinel

# Sprawdz stan klastra przez sentinel
redis-cli -p 26379 sentinel master mymaster
redis-cli -p 26379 sentinel slaves mymaster
redis-cli -p 26379 sentinel sentinels mymaster

Krok 3 — Klienty aplikacji z obsługą Sentinel

Klient nie łączy się bezpośrednio do mastera — pyta sentinel-a o aktualny adres mastera i automatycznie wykrywa failover. Przykłady dla popularnych języków:

# Node.js — ioredis (zalecany dla Sentinel)
# npm install ioredis

const Redis = require('ioredis');

const redis = new Redis({
  sentinels: [
    { host: '10.0.0.1', port: 26379 },
    { host: '10.0.0.2', port: 26379 },
    { host: '10.0.0.3', port: 26379 },
  ],
  name: 'mymaster',
  password: 'MojeHasloRedis2026',
  sentinelPassword: 'MojeHasloRedis2026',
  // Po failover automatycznie reconnectuje
  reconnectOnError: (err) => true,
});

redis.on('connect', () => console.log('Redis connected'));
redis.on('error', (err) => console.error('Redis error:', err));

# PHP — Predis z Sentinel
# composer require predis/predis

use Predis\Client;

$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' => 'MojeHasloRedis2026'],
];

$redis = new Client($sentinels, $options);
$redis->set('klucz', 'wartosc');
echo $redis->get('klucz');

# Python — redis-py z Sentinel
# pip install redis

from redis.sentinel import Sentinel

sentinels = [
    ('10.0.0.1', 26379),
    ('10.0.0.2', 26379),
    ('10.0.0.3', 26379),
]
sentinel = Sentinel(sentinels, socket_timeout=0.5, password='MojeHasloRedis2026')

# Klient do zapisu (master)
master = sentinel.master_for('mymaster', socket_timeout=0.5)
# Klient do odczytu (dowolna replica)
slave = sentinel.slave_for('mymaster', socket_timeout=0.5)

master.set('klucz', 'wartosc')
print(slave.get('klucz'))

Testowanie failover

# Sprawdz aktualny master
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
# Output: 10.0.0.1, 6379

# Symuluj awarie mastera (zatrzymaj Redis na Serwerze A)
sudo systemctl stop redis-server  # na Serwerze A

# Poczekaj ~10-30 sekund
# Sprawdz nowy master
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
# Output: 10.0.0.2, 6379 (lub 10.0.0.3)

# Sprawdz logi sentinel
sudo tail -f /var/log/redis/sentinel.log
# Szukaj: +failover-triggered, +promoted-slave, +failover-end

# Przywroc stary master — automatycznie stanie sie replika!
sudo systemctl start redis-server  # na Serwerze A
redis-cli -h 10.0.0.1 -a "MojeHasloRedis2026" info replication
# role: slave (awansowany po awarii)

Sentinel vs Redis Cluster — porównanie

Najczęstsze pytania