Redis Sentinel für automatisches Failover einrichten

1. Warum Redis Sentinel? Einordnung und Architektur

Redis Sentinel ist die eingebaute Hochverfügbarkeitslösung von Redis für klassische Master-Replica-Setups, bei denen keine Sharding-Anforderung besteht. Ohne Sentinel liegt die Verantwortung für die Erkennung eines Master-Ausfalls und die anschließende Beförderung einer Replica vollständig beim Menschen: Jemand muss den Ausfall bemerken, die geeignetste Replica auswählen, sie per REPLICAOF NO ONE zum Master machen und alle Clients auf die neue Adresse umstellen. Bei einem nächtlichen Ausfall bedeutet das oft Minuten bis Stunden Downtime, während Redis Sentinel denselben Vorgang in der Regel innerhalb weniger Sekunden automatisch durchführt.

Wichtig für das Verständnis ist, dass Redis Sentinel kein Proxy ist, durch den der Traffic fließt. Es handelt sich um separate Redis-Prozesse, die im Sentinel-Modus laufen, die konfigurierten Master und deren Replicas per PING und INFO überwachen und den aktuellen Zustand des Systems kennen. Clients verbinden sich weiterhin direkt mit der Redis-Instanz, fragen aber vorher bei einer Sentinel-Instanz nach der aktuellen Adresse des Masters. Diese Indirektion ist der Kern der Architektur: Sentinel kennt die Wahrheit über den Zustand des Systems, Clients fragen diese Wahrheit ab, statt sie zu erraten.

Eine einzelne Redis Sentinel-Instanz würde selbst zum Single Point of Failure werden, deshalb läuft Sentinel immer als Gruppe von mindestens drei unabhängigen Prozessen, idealerweise auf getrennten Hosts. Diese Gruppe trifft Entscheidungen gemeinsam, nicht durch eine einzelne Instanz. Genau dieses verteilte Entscheidungsmodell mit Quorum und Leader Election ist das Thema des folgenden Abschnitts und der eigentliche Grund, warum Redis Sentinel zuverlässiger ist als ein einfaches Health-Check-Skript mit Failover-Logik.

2. Sentinel-Architektur: Quorum, Voting und Leader Election

Das zentrale Konzept von Redis Sentinel ist die Unterscheidung zwischen subjektivem und objektivem Ausfall. Erkennt eine einzelne Sentinel-Instanz, dass der Master nicht mehr auf PING antwortet, markiert sie ihn intern als Subjectively Down (SDOWN). Das allein löst noch keinen Failover aus, denn es könnte sich um ein lokales Netzwerkproblem dieser einen Sentinel-Instanz handeln. Erst wenn eine ausreichende Anzahl weiterer Sentinels, mindestens das konfigurierte Quorum, denselben Ausfall bestätigt, wird der Master als Objectively Down (ODOWN) eingestuft, und erst ab diesem Zeitpunkt beginnt der eigentliche Failover-Prozess.

Das Quorum wird pro überwachtem Master in der Konfiguration festgelegt und definiert, wie viele Sentinels dem Ausfall zustimmen müssen, damit er als real gilt. Ein Quorum von 2 bei drei Sentinel-Instanzen bedeutet, dass zwei von drei Sentinels unabhängig voneinander den Ausfall bestätigen müssen. Das Quorum allein entscheidet aber noch nicht, wer den Failover tatsächlich durchführt. Dafür braucht es einen zusätzlichen Schritt: Sobald ODOWN erreicht ist, starten die Sentinels eine Leader Election nach einem Raft-inspirierten Verfahren, bei der sich eine Sentinel-Instanz als Leader für die Ausführung des Failovers durchsetzen muss. Für die Wahl des Leaders ist eine echte Mehrheit aller bekannten Sentinels nötig, nicht nur das konfigurierte Quorum, das ist ein häufig übersehener Unterschied.

Dieses zweistufige Modell aus Quorum-basierter Zustandserkennung und mehrheitsbasierter Leader Election macht Redis Sentinel robust gegenüber einzelnen fehlerhaften Beobachtungen. Ein einzelner Sentinel, der aufgrund eines eigenen Netzwerkproblems den Master fälschlich für tot hält, kann keinen Failover auslösen. Nur wenn die Mehrheit der Sentinel-Gruppe unabhängig zum selben Schluss kommt, wird tatsächlich gehandelt. Diese Architektur ist der Grund, warum man Redis Sentinel nie mit nur zwei Instanzen betreiben sollte, dazu mehr im Abschnitt zu Split-Brain-Fallstricken.

3. sentinel.conf: Monitoring-Konfiguration im Detail

Die Konfiguration von Redis Sentinel erfolgt in einer eigenen sentinel.conf, die unabhängig von der normalen redis.conf ist. Die zentrale Direktive ist sentinel monitor, die den Namen der überwachten Master-Gruppe, dessen IP und Port sowie das Quorum festlegt. Alle weiteren Parameter wie down-after-milliseconds, der die Zeit bis zur SDOWN-Markierung bestimmt, oder failover-timeout, der das Zeitfenster für einen einzelnen Failover-Versuch begrenzt, werden relativ zu diesem Master-Namen konfiguriert.

Ein oft unterschätzter Parameter ist parallel-syncs, der festlegt, wie viele Replicas gleichzeitig gegen den neuen Master resynchronisieren dürfen. Ein zu hoher Wert kann bei vielen Replicas die Netzwerkbandbreite des neuen Masters während der Umstellung überlasten, ein zu niedriger Wert verlängert die Zeit, bis alle Replicas wieder konsistent sind. In der Praxis hat sich ein Wert von 1 für Setups mit vielen Replicas bewährt, um den neuen Master während der kritischen Phase nicht zusätzlich zu belasten.

# sentinel.conf: monitoring configuration for one master group
port 26379
sentinel resolve-hostnames yes
sentinel announce-ip 10.0.1.11
sentinel announce-port 26379

# Monitor master "orders-cache" at 10.0.1.10:6379, quorum of 2
sentinel monitor orders-cache 10.0.1.10 6379 2

# Mark SDOWN after 5s of no valid PING reply
sentinel down-after-milliseconds orders-cache 5000

# Only 1 replica resyncs against the new master at a time
sentinel parallel-syncs orders-cache 1

# Abort a stuck failover attempt after 3 minutes
sentinel failover-timeout orders-cache 180000

# Optional: require replica auth
sentinel auth-pass orders-cache s3cur3-replica-pw

# Run a script on every failover event (paging, DNS update, etc.)
sentinel notification-script orders-cache /usr/local/bin/notify-failover.sh
sentinel client-reconfig-script orders-cache /usr/local/bin/update-dns.sh

Bewährt hat sich außerdem, allen drei sentinel.conf-Dateien in einer Gruppe exakt dieselben down-after-milliseconds- und failover-timeout-Werte zu geben. Unterschiedliche Werte auf einzelnen Sentinel-Instanzen führen zu inkonsistentem Timing bei der SDOWN-Erkennung und erschweren die Fehlersuche erheblich, wenn ein Failover später nicht wie erwartet abläuft.

4. Failover-Ablauf: von der Erkennung bis zur Promotion

Der Ablauf eines Failovers in Redis Sentinel folgt immer derselben Sequenz. Zunächst erkennt eine Sentinel-Instanz SDOWN, fragt die anderen konfigurierten Sentinels per SENTINEL is-master-down-by-addr ab und wartet auf deren Bestätigung. Wird das Quorum erreicht, wechselt der Zustand auf ODOWN und die Leader Election beginnt. Der gewählte Leader wählt anschließend unter allen bekannten Replicas die am besten geeignete aus, basierend auf replica-priority, der Menge bereits replizierter Daten und der Replikations-Offset-Position, und führt bei dieser Replica REPLICAOF NO ONE aus.

Nach der Promotion konfiguriert der Sentinel-Leader alle übrigen Replicas so um, dass sie gegen den neuen Master replizieren, und aktualisiert seine interne Sicht auf die Master-Gruppe. Alle anderen Sentinel-Instanzen übernehmen diese neue Konfiguration innerhalb kurzer Zeit. Der gesamte Vorgang, von der ersten SDOWN-Erkennung bis zur vollständigen Umstellung, dauert in gut konfigurierten Setups typischerweise fünf bis fünfzehn Sekunden, abhängig von down-after-milliseconds und der Anzahl der Replicas.

# Inspect Sentinel's live view of the master group
redis-cli -p 26379 sentinel master orders-cache

# List replicas Sentinel currently knows about
redis-cli -p 26379 sentinel replicas orders-cache

# Force a manual failover for testing (do this in staging first)
redis-cli -p 26379 sentinel failover orders-cache

# Typical log sequence during an automatic failover
# +sdown master orders-cache 10.0.1.10 6379
# +odown master orders-cache 10.0.1.10 6379 #quorum 2/2
# +new-epoch 1
# +try-failover master orders-cache 10.0.1.10 6379
# +vote-for-leader <sentinel-id> 1
# +elected-leader master orders-cache 10.0.1.10 6379
# +failover-state-select-slave master orders-cache 10.0.1.10 6379
# +selected-slave slave 10.0.1.12:6379 orders-cache 10.0.1.10 6379
# +failover-state-send-slaveof-noone slave 10.0.1.12:6379 ...
# +failover-state-reconf-slaves master orders-cache 10.0.1.10 6379
# +failover-end master orders-cache 10.0.1.10 6379

Ein Detail, das in Produktionsvorfällen häufig übersehen wird: Ist der alte Master nach seinem Ausfall wieder erreichbar, wird er nicht automatisch wieder zum Master. Redis Sentinel konfiguriert ihn stattdessen als Replica des neu beförderten Masters um, sobald er sich wieder meldet. Das verhindert Split-Brain-Situationen mit zwei gleichzeitig aktiven Mastern, kann aber zu Datenverlust führen, wenn der alte Master zwischen letztem Replikations-Sync und Ausfall noch Schreibzugriffe erhalten hatte, die nie repliziert wurden.

5. Client-Discovery: wie Anwendungen Sentinel nutzen

Anwendungen dürfen die Adresse des Redis-Masters niemals fest verdrahten, wenn Redis Sentinel im Einsatz ist, denn diese Adresse ändert sich bei jedem Failover. Stattdessen kennt der Client die Adressen aller Sentinel-Instanzen und fragt bei Verbindungsaufbau per SENTINEL get-master-addr-by-name nach der aktuellen Master-Adresse. Die meisten modernen Redis-Client-Bibliotheken bieten dafür eingebaute Sentinel-Unterstützung, die diesen Lookup automatisch durchführt und bei einer +switch-master-Meldung transparent neu verbindet.

Wichtig ist, dass der Client mit mehreren Sentinel-Adressen konfiguriert wird, nicht nur einer, damit der Ausfall einer einzelnen Sentinel-Instanz die Discovery nicht blockiert. Zusätzlich sollten Clients auf +switch-master-Pub/Sub-Nachrichten von Sentinel abonnieren können, um Verbindungswechsel proaktiv statt erst beim nächsten fehlgeschlagenen Request zu erkennen. Das reduziert die Anzahl der Requests, die während eines Failover-Fensters gegen die falsche, nicht mehr existierende Master-Adresse laufen.

# Query current master address directly via redis-cli
redis-cli -p 26379 sentinel get-master-addr-by-name orders-cache
# -> 10.0.1.12
# -> 6379

# Subscribe to failover notifications for proactive reconnects
redis-cli -p 26379 subscribe +switch-master
# Example message payload:
# orders-cache 10.0.1.10 6379 10.0.1.12 6379

# Generic client connection pattern (pseudocode, applies to
# most Sentinel-aware client libraries regardless of language)
sentinels = [
  {"host": "10.0.1.11", "port": 26379},
  {"host": "10.0.1.12", "port": 26379},
  {"host": "10.0.1.13", "port": 26379}
]
client = RedisSentinelClient(
  sentinels=sentinels,
  service_name="orders-cache",
  socket_timeout=0.5
)
master = client.master_for("orders-cache")

Ein weiterer Punkt bei der Client-Discovery: Lesende Zugriffe können gezielt gegen Replicas geroutet werden, indem der Client SENTINEL slaves orders-cache abfragt, statt alle Lasten auf den Master zu konzentrieren. Das entlastet den Master und ist besonders bei leseintensiven Workloads relevant. Dabei muss die Anwendung akzeptieren, dass Replica-Reads leicht veraltete Daten liefern können, da Replikation asynchron erfolgt.

6. Sentinel-Cluster betreiben: Anzahl, Platzierung, Netzwerk

Die Anzahl der Redis Sentinel-Instanzen sollte immer ungerade sein, üblich sind drei oder fünf. Eine ungerade Anzahl verhindert Patt-Situationen bei der mehrheitsbasierten Leader Election. Drei Sentinels reichen für die meisten Setups aus und tolerieren den Ausfall einer Instanz, ohne die Failover-Fähigkeit zu verlieren. Fünf Instanzen erhöhen die Fehlertoleranz weiter und sind sinnvoll, wenn die Infrastruktur über drei oder mehr Availability Zones verteilt ist.

Die physische Platzierung ist ebenso wichtig wie die Anzahl. Jede Sentinel-Instanz sollte auf einem anderen Host laufen als die anderen Sentinels, und idealerweise auch getrennt von den Redis-Datenknoten selbst, damit ein Host-Ausfall nicht gleichzeitig eine Sentinel-Instanz und einen Redis-Knoten mitreißt. In Cloud-Umgebungen bedeutet das, Sentinels über verschiedene Availability Zones zu verteilen. Ein häufiges Anti-Pattern ist, alle drei Sentinels auf denselben drei Hosts wie Master und Replicas zu betreiben, ohne die Zuordnung zu durchmischen, das verringert die tatsächliche Fehlertoleranz erheblich.

# Recommended topology: 3 Sentinels spread across 3 AZs,
# each AZ also hosting one Redis data node (master or replica)

# AZ-a: redis-master + sentinel-1
# AZ-b: redis-replica-1 + sentinel-2
# AZ-c: redis-replica-2 + sentinel-3

# Start Sentinel with its own dedicated config file
redis-sentinel /etc/redis/sentinel.conf --daemonize no

# systemd unit snippet for production deployment
# [Unit]
# Description=Redis Sentinel
# After=network.target
# [Service]
# ExecStart=/usr/bin/redis-sentinel /etc/redis/sentinel.conf
# Restart=always
# User=redis
# [Install]
# WantedBy=multi-user.target

Ein oft unterschätztes Detail: Redis Sentinel schreibt seine erkannte Konfiguration, etwa nach einem Failover, in die eigene sentinel.conf zurück. Diese Datei muss deshalb beschreibbar sein und darf nicht durch Configuration-Management-Tools bei jedem Deploy überschrieben werden, sonst verliert Sentinel nach einem Neustart sein zuletzt bekanntes, korrektes Bild vom aktuellen Master.

7. Split-Brain und Quorum-Fallstricke vermeiden

Ein Split-Brain-Szenario entsteht, wenn ein Netzwerkpartition-Ereignis die Sentinel-Gruppe in zwei isolierte Hälften teilt und beide Hälften unabhängig voneinander glauben, den Master korrekt zu sehen. Bei einem Quorum von 2 unter drei Sentinels kann eine Partition mit zwei Sentinels einen Failover auslösen, während die isolierte dritte Instanz weiterhin den alten Master für gesund hält. Solange Clients auf der isolierten Seite weiterhin gegen den alten Master schreiben, entstehen Daten, die nach Ende der Partition verloren gehen, weil der alte Master zur Replica des neuen wird.

Um dieses Risiko zu minimieren, sollte das Quorum nie kleiner als die Hälfte plus eins der Sentinel-Instanzen gewählt werden, auch wenn Redis technisch kleinere Werte zulässt. Zusätzlich schützt der Parameter min-replicas-to-write auf dem Redis-Master selbst davor, dass ein isolierter Master, der keine Verbindung mehr zu genügend Replicas hat, weiterhin Schreibzugriffe akzeptiert. Kombiniert mit min-replicas-max-lag verweigert der Master Schreibzugriffe, sobald zu wenige Replicas aktuell genug angebunden sind, was das Zeitfenster für Datenverlust bei einem Split-Brain deutlich verkürzt.

# redis.conf on the master: reject writes if fewer than 1
# replica is connected with an ack lag under 10 seconds
min-replicas-to-write 1
min-replicas-max-lag 10

# Check current replica ack status live
redis-cli -p 6379 info replication
# connected_slaves:2
# slave0:ip=10.0.1.12,port=6379,state=online,offset=88213,lag=0
# slave1:ip=10.0.1.13,port=6379,state=online,offset=88213,lag=1

Eine dritte Absicherung ist ein sauber konfiguriertes failover-timeout. Bricht ein Failover-Versuch nicht innerhalb dieses Zeitfensters ab, startet Redis Sentinel automatisch einen neuen Versuch mit einer neuen Epoche, was wiederholte, inkonsistente Zustände verhindert. Wer diese drei Mechanismen kombiniert, Quorum als echte Mehrheit, min-replicas-to-write und ein realistisches failover-timeout, reduziert das Split-Brain-Risiko auf ein in der Praxis vernachlässigbares Niveau.

8. Monitoring und Health-Checks für Sentinel selbst

Sentinel überwacht Redis, aber Sentinel selbst muss ebenfalls überwacht werden, sonst bemerkt niemand, wenn die Hochverfügbarkeitsschicht ausfällt, während Redis noch normal läuft. Der Befehl SENTINEL info-cache und die Standard-INFO-Ausgabe jeder Sentinel-Instanz liefern Kennzahlen wie die Anzahl bekannter Sentinels, die Anzahl bekannter Replicas und den aktuellen Zustand des Masters aus Sicht dieser Instanz. Weichen diese Werte zwischen den drei Sentinel-Instanzen voneinander ab, deutet das auf ein Netzwerkproblem oder eine fehlerhafte Konfiguration hin.

In der Praxis hat es sich bewährt, ein externes Monitoring-System regelmäßig SENTINEL master orders-cache auf allen drei Instanzen abzufragen und die zurückgegebenen num-other-sentinels- und num-slaves-Werte zu vergleichen. Ein dauerhaft niedrigerer Wert auf einer Instanz zeigt, dass diese Sentinel die anderen nicht mehr vollständig sieht, lange bevor ein tatsächlicher Failover das Problem sichtbar macht. Auch das Alarm-Skript aus notification-script sollte nicht nur bei echten Failovers, sondern auch bei SDOWN-Ereignissen ohne anschließendes ODOWN Alarm schlagen, weil solche Flapping-Muster auf instabile Netzwerkverbindungen hindeuten.

# Cross-check Sentinel state consistency across all instances
for port in 26379 26380 26381; do
  echo "=== sentinel on port $port ==="
  redis-cli -p "$port" sentinel master orders-cache | \
    grep -E "num-other-sentinels|num-slaves|flags"
done

# Watch for flapping SDOWN events in the log (instability signal)
grep -c "+sdown" /var/log/redis/sentinel.log

# Confirm all three Sentinels agree on the current master
redis-cli -p 26379 sentinel get-master-addr-by-name orders-cache
redis-cli -p 26380 sentinel get-master-addr-by-name orders-cache
redis-cli -p 26381 sentinel get-master-addr-by-name orders-cache

Ergänzend lohnt sich ein einfacher End-to-End-Check, der periodisch tatsächlich einen Wert über die von Sentinel zurückgegebene Master-Adresse schreibt und liest. Das deckt Szenarien auf, in denen Sentinel selbst gesund erscheint, aber der Redis-Master aus einem anderen Grund keine Schreibzugriffe mehr annimmt, etwa wegen einer vollen Persistenz-Disk. Reines Sentinel-Monitoring allein ersetzt nie ein funktionales Monitoring der eigentlichen Datenbank.

9. Redis Sentinel im Vergleich zu anderen Ansätzen

Neben Redis Sentinel gibt es weitere Ansätze für Hochverfügbarkeit, und die Wahl hängt stark vom vorhandenen Ökosystem ab. Manuelle Failover-Skripte mit Health-Checks über Cron oder externe Monitoring-Tools bieten volle Kontrolle, sind aber fehleranfällig, weil sie das Quorum- und Leader-Election-Problem meist gar nicht sauber lösen. Redis Cluster löst Hochverfügbarkeit ebenfalls, kombiniert sie aber untrennbar mit Sharding, was für Setups, die kein Sharding brauchen, unnötige operative Komplexität bedeutet.

Für Setups, die primär Ausfallsicherheit statt Kapazitätserweiterung brauchen, bleibt Redis Sentinel die schlankste eingebaute Lösung. Der Umstieg von Sentinel auf Cluster lohnt sich erst, sobald die Datenmenge oder der Schreib-Durchsatz die Kapazität eines einzelnen Masters übersteigt, nicht schon wegen des Wunsches nach Automatisierung allein.

10. Zusammenfassung

Redis Sentinel für automatisches Failover löst ein konkretes Betriebsproblem: Ohne Automatisierung entscheidet die Reaktionszeit eines Menschen über die Ausfallzeit. Die zweistufige Architektur aus subjektiver Ausfallerkennung, quorumbasierter Bestätigung und mehrheitsbasierter Leader Election macht Sentinel robust gegenüber Fehlalarmen einzelner Instanzen. Eine saubere sentinel.conf mit passenden Werten für down-after-milliseconds, parallel-syncs und failover-timeout ist die Grundlage jedes stabilen Setups.

Genauso wichtig wie die Konfiguration von Sentinel selbst ist die korrekte Client-Discovery: Anwendungen dürfen die Master-Adresse nie fest verdrahten, sondern müssen sie über Sentinel abfragen und auf +switch-master-Ereignisse reagieren. Mit mindestens drei über getrennte Availability Zones verteilten Sentinel-Instanzen, einem realistischen Quorum und ergänzendem Schutz durch min-replicas-to-write lässt sich das Split-Brain-Risiko auf ein vernachlässigbares Niveau senken, ohne die operative Einfachheit eines klassischen Master-Replica-Setups aufzugeben.

11. FAQ: Redis Sentinel für automatisches Failover