Redis Sentinel — wysoka dostępność Redis na VPS

Opublikowano: 9 kwietnia 2026 · Kategoria: VPS

Redis jest ultra-szybki, ale jednoserwerowy — gdy maszyna padnie, cache znika i aplikacja spada na zimną bazę danych. Redis Sentinel to wbudowany system wysokiej dostępności (HA): monitoruje mastera, automatycznie promuje replikę i powiadamia aplikacje o zmianie adresu. Oto jak go skonfigurować krok po kroku.

Architektura: master, replica, Sentinel

Typowy setup Redis Sentinel składa się z trzech warstw:

• Master Redis — przyjmuje zapisy, replikuje dane do replik asynchronicznie.
• Replica (1-2 szt.) — kopie mastera w trybie read-only. Po failoverze jedna zostaje promowana na nowego mastera.
• Sentinel (min. 3 szt.) — osobny proces (port 26379) który monitoruje mastera i repliki. Sentinele głosują (quorum) czy master jest niedostępny, a następnie koordynują failover.

W produkcji minimalna topologia to: 3 serwery VPS, każdy z procesem Redis i procesem Sentinel. Jeden serwer pełni rolę mastera, dwa pozostałe — replik. Sentinel może działać na tych samych serwerach co Redis.

Konfiguracja repliki

Na serwerach repliki edytuj /etc/redis/redis.conf i wskaż mastera:

# /etc/redis/redis.conf na REPLICE (np. 10.0.0.11 i 10.0.0.12)

replicaof 10.0.0.10 6379        # IP mastera i port

# Opcjonalnie: replika read-only (domyślnie tak)
replica-read-only yes

# Uwierzytelnianie (jeśli master ma hasło)
masterauth TwojeHaslo123
requirepass TwojeHaslo123       # Takie samo na wszystkich węzłach

# Restart Redis na replice
sudo systemctl restart redis-server

# Sprawdź replikację
redis-cli -a TwojeHaslo123 info replication

W odpowiedzi na replikach powinieneś zobaczyć role:slave i master_link_status:up. Na masterze — role:master i listę podłączonych replik.

Konfiguracja sentinel.conf

Utwórz plik /etc/redis/sentinel.conf na każdym z 3 serwerów (konfiguracja identyczna):

# /etc/redis/sentinel.conf

port 26379
daemonize yes
logfile /var/log/redis/sentinel.log
pidfile /var/run/redis/redis-sentinel.pid

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

# Hasło do mastera (jeśli ustawione)
sentinel auth-pass mymaster TwojeHaslo123

# Po ilu ms bez odpowiedzi uznać mastera za niedostępnego
sentinel down-after-milliseconds mymaster 5000

# Limit czasu na failover (ms)
sentinel failover-timeout mymaster 60000

# Ile replik jednocześnie synchronizuje się z nowym masterem
sentinel parallel-syncs mymaster 1

# Uruchomienie Sentinel
sudo redis-sentinel /etc/redis/sentinel.conf

# Lub przez systemd (utwórz /etc/systemd/system/redis-sentinel.service)
# ExecStart=/usr/bin/redis-sentinel /etc/redis/sentinel.conf

# Sprawdź status
redis-cli -p 26379 sentinel masters
redis-cli -p 26379 sentinel slaves mymaster
redis-cli -p 26379 sentinel sentinels mymaster

Parametry sentinel.conf — wyjaśnienie

Testowanie failover

Przetestuj failover bez przerywania działania serwera — użyj polecenia Sentinel:

# Wymuś failover (Sentinel sam wybierze nowego mastera)
redis-cli -p 26379 sentinel failover mymaster

# Obserwuj logi w czasie rzeczywistym
tail -f /var/log/redis/sentinel.log

# Sprawdź który węzeł jest teraz masterem
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

Możesz też zasymulować awarię mastera przez redis-cli -p 6379 DEBUG sleep 30 (master przestaje odpowiadać na 30 sekund) i obserwować jak Sentinel reaguje.

Połączenie aplikacji przez Sentinel

Aplikacja nie łączy się bezpośrednio z IP mastera — odpytuje Sentinel o aktualny adres. Przykłady dla popularnych języków:

// Node.js (ioredis)
import Redis from 'ioredis';

const redis = new Redis({
  sentinels: [
    { host: '10.0.0.10', port: 26379 },
    { host: '10.0.0.11', port: 26379 },
    { host: '10.0.0.12', port: 26379 },
  ],
  name: 'mymaster',
  password: 'TwojeHaslo123',
  sentinelPassword: 'TwojeHaslo123',
});

# Python (redis-py)
from redis.sentinel import Sentinel

sentinel = Sentinel([
    ('10.0.0.10', 26379),
    ('10.0.0.11', 26379),
    ('10.0.0.12', 26379),
], socket_timeout=0.1, password='TwojeHaslo123')

master = sentinel.master_for('mymaster', socket_timeout=0.1)
slave  = sentinel.slave_for('mymaster', socket_timeout=0.1)

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

# PHP (predis)
$sentinel = new Predis\Client([
    ['scheme' => 'redis', 'host' => '10.0.0.10', 'port' => 26379],
    ['scheme' => 'redis', 'host' => '10.0.0.11', 'port' => 26379],
    ['scheme' => 'redis', 'host' => '10.0.0.12', 'port' => 26379],
], [
    'replication' => 'sentinel',
    'service'     => 'mymaster',
]);

Redis Sentinel vs Redis Cluster

Dla większości projektów hostingowych — WordPress z Redis object cache, Next.js session store, kolejki zadań — Sentinel jest wystarczający i łatwiejszy w utrzymaniu. Redis Cluster ma sens dopiero przy setkach gigabajtów danych.

Najczęstsze pytania