Autor: [Adam Nadolny](/autorzy/adam-nadolny) Ekspert DevOps i infrastruktury · Zweryfikowano Kwiecień 2026 1. [Strona główna](/) › 2. [Baza wiedzy](/baza-wiedzy/) › 3. Redis Sentinel — High Availability # 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 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 Aspekt Redis Sentinel Redis Cluster Cel High Availability (HA) HA + Horizontal Scaling Dane Jeden dataset na master Sharding na wielu masterach (16384 slotów) Min. węzły 3 (sentinel + Redis) 6 (3 master + 3 replica) Klient Wymaga Sentinel-aware client Wymaga Cluster-aware client Multi-key operacje Pełna obsługa Tylko gdy klucze w tym samym slocie Złożoność Niska Wysoka Kiedy użyć Dataset < RAM jednego serwera Dataset > RAM lub wysoki throughput zapisu ## Najczęstsze pytania Co to jest Redis Sentinel i jak działa failover? + Redis Sentinel to system zarządzania HA (High Availability) dla Redis. Uruchamiasz minimum 3 procesy sentinel na osobnych serwerach, które monitorują mastera i repliki. Gdy master przestaje odpowiadać przez quorum\_timeout, sentinele głosują (quorum) i automatycznie awansują najlepszą replikę na nowego mastera. Klienty są powiadamiane o nowym masterze przez mechanizm Sentinel discovery (pytają sentinel-a o aktualny adres mastera). Cały failover zajmuje 10-30 sekund. Ile sentineli potrzebuję i dlaczego 3? + Minimalna zalecana liczba to 3. Sentinel używa kworum (większości) do podjęcia decyzji o failover — chroni to przed split-brain (sytuacją gdy część sieci myśli że master żyje, a część że nie). Przy 3 sentinelach kworum = 2: nawet jeśli jeden sentinel jest niedostępny, dwóch może podjąć decyzję. Przy 2 sentinelach kworum = 2, więc awaria jednego blokuje failover. Używaj 3 lub 5 sentineli (zawsze nieparzysta liczba) na osobnych hostach lub strefach dostępności. Jaka jest różnica między Redis Sentinel a Redis Cluster? + Redis Sentinel zapewnia HA dla jednego zestawu master-replica: automatyczny failover gdy master padnie, ale dane są na jednej maszynie (jeden shard). Redis Cluster to sharding — dane są podzielone na 16384 slotów i rozłożone na wiele masterów (np. 3-6). Cluster daje HA + skalowalność poziomą. Użyj Sentinel gdy: masz jeden duży dataset, nie potrzebujesz shardingu, chcesz prostej konfiguracji. Użyj Cluster gdy: dataset przekracza RAM jednego serwera lub potrzebujesz skalowalności zapisu. Jak klient PHP/Node.js powinien obsługiwać Redis Sentinel? + Klient musi obsługiwać protokół Sentinel — nie łączy się bezpośrednio do mastera, lecz pyta sentinel-a o aktualny adres mastera. PHP: Predis (lista adresów sentinel + nazwa master) lub phpredis z sentinel support. Node.js: ioredis (opcja sentinels: \[{host,port}\], name: "mymaster"). Python: redis-py (Sentinel klasa). Klienty automatycznie wykrywają failover i przełączają się na nowy master bez przerwy (z krótką chwilową niedostępnością podczas failover ~10-30s). ## Sprawdź oferty pasujące do tego scenariusza Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne. Contabo VPS do klastra Redis Sentinel — 3 węzły sentinel na 3 instancjach VPS VPS HA Cluster [Aktywuj rabat →](/out/contabo) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/contabo) Mikr.us Tani VPS do nauki konfiguracji Redis Sentinel w środowisku testowym Dev/Test [Aktywuj rabat →](/out/mikrus) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/mikrus) LH.pl Hosting z gotowym Redis w chmurze — bez potrzeby zarządzania Sentinel Managed Redis [Aktywuj rabat →](/out/lh-pl) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/lh-pl) ## Powiązane strony - [Memcached vs Redis — porównanie](/baza-wiedzy/memcached-vs-redis-hosting) - [pgBouncer — connection pooling PostgreSQL](/baza-wiedzy/pgbouncer-postgresql-pooling) - [Netdata — real-time monitoring VPS](/baza-wiedzy/netdata-monitoring-vps) - [Wszystkie artykuły](/baza-wiedzy/)