Ghid de Înaltă Disponibilitate cu Redis Sentinel: Arhitectură Master-Replica, Quorum și Failover Automat în Redis & In-Memory Data Store

Ghid complet de producție pentru configurarea Redis Sentinel: topologie cu minimum 3 instanțe, detecția defecțiunilor prin sdown și odown, consens prin quorum, alegerea automată a liderului și failover fără pierdere de date.

Sintaxă comandă
sentinel monitor mymaster 10.0.0.1 6379 2 | sentinel down-after-milliseconds mymaster 5000

Într-un mediu enterprise, căderea nodului Master de Redis nu trebuie să întrerupă funcționarea aplicațiilor. Redis Sentinel este sistemul distribuit oficial de monitorizare, notificare și recuperare automată în caz de dezastru (Automatic Failover) pentru topologiile Master-Replica.

Pentru a garanta decizii corecte și a preveni fenomenul catastrofal de Split-Brain (situația în care două noduri cred concomitent că sunt Master și acceptă scrieri divergente), o arhitectură de producție necesită minimum 3 instanțe Sentinel amplasate pe servere fizice sau zone de disponibilitate (AZ) independente.

Fișier de Configurare de Producție (sentinel.conf)
# Portul standard de ascultare pentru instanța Sentinel:
port 26379
dir /var/lib/redis/sentinel

# 1. Definirea clusterului monitorizat:
# Sintaxă: sentinel monitor    
# Quorum = 2: Este nevoie de votul favorabil a cel puțin 2 noduri Sentinel pentru a declara căderea!
sentinel monitor mymaster 10.0.0.10 6379 2

# Parola de autentificare pe nodurile Redis protejate cu ACL:
sentinel auth-user mymaster sentinel_admin
sentinel auth-pass mymaster ParolaUltraSigura2026!

# 2. Pragul de timp după care nodul este considerat căzut (Subjective Down):
# Dacă masterul nu răspunde la comenzi PING timp de 5000 ms (5 secunde):
sentinel down-after-milliseconds mymaster 5000

# 3. Timeout-ul procesului de failover:
sentinel failover-timeout mymaster 30000

# 4. Numărul de replici care pot fi reconfigurate concomitent în timpul failover-ului:
# Setați la 1 pentru a evita supraîncărcarea rețelei și a păstra celelalte replici capabile de citiri:
sentinel parallel-syncs mymaster 1

Procesul de Decizie: SDOWN vs. ODOWN și Algoritmul Raft

  1. Subjectively Down (SDOWN): O instanță Sentinel individuală trimite comenzi PING la fiecare secundă. Dacă nu primește răspuns valid în intervalul down-after-milliseconds, marchează masterul ca indisponibil la nivel local.
  2. Objectively Down (ODOWN): Instanța Sentinel interoghează celelalte noduri Sentinel active prin comanda SENTINEL is-master-down-by-addr. Dacă numărul de confirmări atinge valoarea parametrului Quorum, starea devine ODOWN.
  3. Alegerea Liderului de Failover: Nodurile Sentinel folosesc algoritmul de consens Raft pentru a alege o instanță Sentinel lider responsabilă de execuția procedurii.
  4. Selecția Replicului Promovat: Liderul alege cea mai adecvată replică pe baza:
    • Priorității configurate (replica-priority mai mic de 100, unde 0 înseamnă că nu va fi promovat niciodată).
    • Celui mai avansat offset de date (Replication Offset — replica care are cele mai puține date pierdute).
    • În caz de egalitate, nodul cu cel mai mic identificator lexicografic (runid).
  5. Reconfigurarea Automată: Liderul transmite comanda REPLICAOF NO ONE către replica aleasă, apoi trimite REPLICAOF ip_nou port_nou către celelalte noduri secundare și notifică clienții prin mesaje Pub/Sub pe canalul +switch-master.