Redis Sentinel Guide: Hochverfügbarkeit und automatisches Failover

23. März 2026

12 Min. Lesezeit

Aktuell

TL;DR — Kurzzusammenfassung

Redis Sentinel für automatisches Failover und Hochverfügbarkeit einrichten. Quorum, Master-Replikat-Topologie, Sentinel-Clients und Sicherheit konfigurieren.

Redis Sentinel ist die in Redis integrierte Hochverfügbarkeitslösung, die automatisches Failover, Topologie-Überwachung und Service-Discovery ohne die Komplexität von Redis Cluster bietet. Dieser Leitfaden behandelt die vollständige Architektur, eine produktionsreife Drei-Knoten-Bereitstellung, die Konfiguration Sentinel-fähiger Clients, Quorum-Konzepte und die Sicherheitskontrollen, die vor der Produktivschaltung erforderlich sind.

Voraussetzungen

Drei Linux-Server (physisch oder virtuell), die sich gegenseitig auf den Ports 6379 (Redis) und 26379 (Sentinel) erreichen können.
Redis 7.0 oder höher auf allen Knoten installiert.
Root- oder sudo-Zugriff auf jedem Server.
Grundlegende Vertrautheit mit Redis-Konfigurationsdateien und redis-cli.

Sentinel-Architektur

Redis Sentinel wird als separater Prozess neben Ihren Redis-Instanzen ausgeführt. Jeder Sentinel übernimmt vier Rollen:

Überwachung: Überprüft jede Sekunde die Gesundheit von Master und Replikaten über PING/INFO.
Benachrichtigung: Veröffentlicht Meldungen auf Kanälen wie +switch-master und +slave über Pub/Sub.
Automatisches Failover: Sobald das Quorum erreicht ist, wählt Sentinel einen Leader, befördert das beste Replikat und konfiguriert die übrigen neu.
Konfigurationsanbieter: Clients fragen Sentinel mit SENTINEL get-master-addr-by-name nach der aktuellen Master-Adresse.

Warum Drei Sentinels?

Ein einzelner Sentinel ist ein Single Point of Failure. Zwei Sentinels können zu einem Stimmengleichstand führen. Drei Sentinels mit Quorum 2 garantieren:

Ein Sentinel kann ausfallen und das Failover funktioniert noch.
Zwei beliebige Sentinels können sich auf die Beförderung eines neuen Masters einigen.
Die Minderheit kann keine Beförderung auslösen, die zu Split-Brain führen würde.

Setzen Sie immer eine ungerade Anzahl von Sentinels ein (3, 5 oder 7).

Schritt 1 — Den Redis-Master konfigurieren

Auf Server 1 (192.168.1.101), bearbeiten Sie /etc/redis/redis.conf:

bind 0.0.0.0
port 6379
protected-mode no

requirepass "StarkesRedisPasswort123"
masterauth "StarkesRedisPasswort123"

# Persistenz (AOF für Sentinel-Bereitstellungen empfohlen)
appendonly yes
appendfsync everysec

# Split-Brain-Schutz: Schreibvorgänge ablehnen, wenn kein Replikat in 10s synchronisiert hat
min-replicas-to-write 1
min-replicas-max-lag 10

Redis starten und aktivieren:

sudo systemctl start redis-server
sudo systemctl enable redis-server

Schritt 2 — Redis-Replikate konfigurieren

Auf Server 2 (192.168.1.102) und Server 3 (192.168.1.103), bearbeiten Sie /etc/redis/redis.conf:

bind 0.0.0.0
port 6379
protected-mode no

requirepass "StarkesRedisPasswort123"
masterauth "StarkesRedisPasswort123"

# Auf den anfänglichen Master zeigen
replicaof 192.168.1.101 6379

# Replikate verweigern Schreibbefehle von Clients (sichere Standardeinstellung)
replica-read-only yes

# Persistenz
appendonly yes
appendfsync everysec

# Beförderungspriorität des Replikats (niedriger = bevorzugt; 0 = niemals befördern)
replica-priority 100

Replikation vom Master aus überprüfen:

redis-cli -a "StarkesRedisPasswort123" INFO replication

Sie sollten role:master und zwei slave-Einträge mit state:online sehen.

Schritt 3 — Redis Sentinel konfigurieren

Erstellen Sie /etc/redis/sentinel.conf auf allen drei Servern:

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
dir /var/lib/redis

# Den Master namens "mymaster" mit Quorum 2 überwachen
sentinel monitor mymaster 192.168.1.101 6379 2

# Passwort zur Authentifizierung beim Master (und Replikaten nach Failover)
sentinel auth-pass mymaster StarkesRedisPasswort123

# Master nach 5 Sekunden ohne Antwort als SDOWN markieren
sentinel down-after-milliseconds mymaster 5000

# Maximale Zeit für den gesamten Failover-Prozess (ms)
sentinel failover-timeout mymaster 60000

# Nur ein Replikat synchronisiert gleichzeitig vom neuen Master
sentinel parallel-syncs mymaster 1

Sentinel auf allen drei Servern starten:

sudo redis-sentinel /etc/redis/sentinel.conf

Topologie-Erkennung überprüfen:

redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster
redis-cli -p 26379 SENTINEL ckquorum mymaster

Der Failover-Prozess Schritt für Schritt

SDOWN (Subjektiv ausgefallen): Ein Sentinel erhält innerhalb von down-after-milliseconds kein PONG vom Master und markiert ihn als SDOWN.
ODOWN (Objektiv ausgefallen): Der Sentinel sendet SENTINEL is-master-down-by-addr an seine Peers. Wenn das Quorum positiv antwortet, wechselt der Zustand zu ODOWN.
Leader-Wahl: Sentinels, die ODOWN bestätigen, wählen mithilfe des Raft-ähnlichen Algorithmus von Sentinel einen Leader.
Replikat-Auswahl: Der Leader bewertet Replikate nach: Trennungszeit vom Master → replica-priority (niedriger gewinnt) → Replikations-Offset (mehr Daten gewinnt) → lexikografische Run-ID.
Beförderung: Der Leader sendet REPLICAOF NO ONE an das ausgewählte Replikat und macht es zum neuen Master.
Neukonfiguration: Alle anderen Replikate erhalten REPLICAOF <neue-master-ip> 6379. Sentinels aktualisieren ihre sentinel.conf-Dateien. Clients, die Sentinel abfragen, erhalten nun die neue Master-Adresse.

Der gesamte Prozess wird mit den Standardeinstellungen typischerweise in 10–30 Sekunden abgeschlossen.

Client-Verbindung über Sentinel

Codieren Sie die Redis-Master-IP niemals fest in Ihrer Anwendung. Verwenden Sie einen Sentinel-fähigen Client, der Sentinel nach dem aktuellen Master befragt.

Python (redis-py)

from redis.sentinel import Sentinel

sentinel = Sentinel(
    [
        ("192.168.1.101", 26379),
        ("192.168.1.102", 26379),
        ("192.168.1.103", 26379),
    ],
    socket_timeout=0.5,
    password="StarkesRedisPasswort123",
)

master = sentinel.master_for("mymaster", socket_timeout=0.5)
replica = sentinel.slave_for("mymaster", socket_timeout=0.5)

master.set("sitzung:abc", "benutzer-daten")
wert = replica.get("sitzung:abc")

Node.js (ioredis)

const Redis = require("ioredis");

const redis = new Redis({
  sentinels: [
    { host: "192.168.1.101", port: 26379 },
    { host: "192.168.1.102", port: 26379 },
    { host: "192.168.1.103", port: 26379 },
  ],
  name: "mymaster",
  password: "StarkesRedisPasswort123",
  sentinelPassword: "StarkesRedisPasswort123",
});

await redis.set("schluessel", "wert");

Sicherheit in der Produktion

Sentinel absichern

Fügen Sie requirepass zu Sentinel hinzu, damit nur autorisierte Clients Sentinel-Befehle ausgeben können:

requirepass "SentinelAdminPasswort"
sentinel sentinel-pass SentinelAdminPasswort

TLS aktivieren

Redis 6.0+ unterstützt TLS für Redis- und Sentinel-Verbindungen:

tls-port 26380
port 0
tls-cert-file /etc/redis/tls/sentinel.crt
tls-key-file /etc/redis/tls/sentinel.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-replication yes

ACLs verwenden (Redis 6.0+)

# In redis.conf
aclfile /etc/redis/users.acl

# users.acl
user default off
user sentinel on >SentinelPass ~* &* +@all
user app on >AppPass ~sitzung:* ~cache:* +GET +SET +DEL +EXPIRE

Vergleich: Sentinel vs. Alternativen

Funktion	Sentinel	Redis Cluster	KeyDB	Dragonfly	Verwaltetes Redis
Automatisches Failover	Ja	Ja	Ja	Ja	Ja
Daten-Sharding	Nein	Ja	Ja	Nein	Variiert
Konfigurationskomplexität	Mittel	Hoch	Niedrig	Niedrig	Keine
Client-Anforderung	Sentinel-fähig	Cluster-fähig	Standard	Standard	Standard
Maximale Datenmenge	RAM eines Knotens	RAM × Shards	RAM eines Knotens	RAM eines Knotens	Planbegrenzt
Kosten	Kostenlos	Kostenlos	Kostenlos	Kostenlos	$$/Monat
Ideal für	HA ohne Sharding	Große Datensätze	Redis-HA-Drop-in	Hoher Durchsatz	Ohne Infra-Verwaltung

Häufige Probleme und Fallstricke

Sentinel überschreibt seine Konfigurationsdatei. Bearbeiten Sie sentinel.conf niemals manuell, während Sentinel läuft — Sentinel aktualisiert die Datei ständig mit der entdeckten Topologie.

DNS vs. IP-Adressen. Sentinel speichert Master- und Replikat-Adressen beim Erkennen als IP-Adressen. Wenn Sie die IP eines Servers ändern, folgt Sentinel nicht den DNS-Änderungen.

Veraltete Lesevorgänge während des Failovers. In den 10–30 Sekunden zwischen dem Master-Ausfall und der Replikat-Beförderung können Lesevorgänge veraltete Daten zurückgeben. Entwerfen Sie Ihre Anwendung so, dass sie kurze veraltete Lesevorgänge toleriert.

requirepass ohne masterauth. Wenn Sie requirepass auf dem Master setzen, aber masterauth auf den Replikaten vergessen, schlägt die Replikationsauthentifizierung fehl und Replikate trennen sich stillschweigend.

Zusammenfassung

Redis Sentinel bietet Überwachung, automatisches Failover und Service-Discovery für Redis ohne Cluster-Anforderungen.
Stellen Sie mindestens 3 Sentinel-Instanzen auf separaten Hosts bereit; setzen Sie Quorum auf 2 für eine 3-Knoten-Konfiguration.
Die Failover-Sequenz schreitet von SDOWN → ODOWN → Leader-Wahl → Replikat-Beförderung → Neukonfiguration fort.
Verwenden Sie min-replicas-to-write und min-replicas-max-lag auf dem Master, um Datenverlust durch Split-Brain zu verhindern.
Verwenden Sie immer einen Sentinel-fähigen Client — codieren Sie die Master-IP niemals fest.
Sichern Sie Sentinel mit requirepass, ACLs und TLS in Produktionsumgebungen.

Guide & Instructions

Estimated Time: 30m

Tools Needed:

Redis
Redis Sentinel
systemctl

Redis auf allen drei Knoten installieren

Installieren Sie Redis 7.0 oder höher auf dem Master-Server und den beiden Replikat-Servern. Stellen Sie sicher, dass die Ports 6379 und 26379 zwischen allen Knoten in den Firewall-Regeln geöffnet sind.

Den Redis-Master konfigurieren

Bearbeiten Sie /etc/redis/redis.conf auf dem Master-Knoten. Setzen Sie bind auf 0.0.0.0, requirepass, masterauth und Persistenzoptionen. Fügen Sie min-replicas-to-write 1 und min-replicas-max-lag 10 hinzu, um Split-Brain zu verhindern.

Redis-Replikate konfigurieren

Bearbeiten Sie auf jedem Replikat-Knoten redis.conf, um die replicaof-Direktive hinzuzufügen, die auf IP und Port des Masters zeigt. Konfigurieren Sie replica-read-only yes und verwenden Sie dieselben requirepass- und masterauth-Werte wie der Master.

sentinel.conf auf jedem Knoten erstellen und bereitstellen

Erstellen Sie /etc/redis/sentinel.conf auf jedem der drei Server mit sentinel monitor mymaster, das auf den Master zeigt, Quorum 2, down-after-milliseconds 5000, failover-timeout 60000 und sentinel auth-pass mit dem Master-Passwort.

Sentinel starten und Topologie-Erkennung überprüfen

Starten Sie Redis Sentinel mit 'sudo redis-sentinel /etc/redis/sentinel.conf' auf allen Knoten. Führen Sie 'redis-cli -p 26379 SENTINEL masters' aus, um zu bestätigen, dass alle drei Sentinels denselben Master sehen und sich gegenseitig entdeckt haben.

Automatisches Failover testen und Anwendungsclients aktualisieren

Stoppen Sie den Redis-Master-Prozess und beobachten Sie die Sentinel-Logs. Bestätigen Sie, dass ein Replikat innerhalb von Sekunden befördert wird. Aktualisieren Sie die Anwendung, um einen Sentinel-fähigen Client zu verwenden, der auf alle drei Sentinel-Adressen zeigt.

Frequently Asked Questions

Wie erkennt Redis Sentinel einen Master-Ausfall?

Jeder Sentinel sendet jede Sekunde einen Ping an den Master. Bleibt eine Antwort innerhalb von down-after-milliseconds aus, markiert dieser Sentinel den Master als SDOWN. Wenn das Quorum der Sentinels übereinstimmt, wechselt der Zustand zu ODOWN und das Failover beginnt.

Wie viele Sentinel-Instanzen werden mindestens benötigt?

Es werden mindestens 3 Sentinel-Instanzen mit einem Quorum von 2 benötigt. Eine ungerade Zahl verhindert Stimmengleichheit bei der Leader-Wahl, und der Ausfall eines Sentinels lässt noch genug Instanzen übrig, um das Quorum zu erreichen und das Failover sicher auszulösen.

Fungiert Redis Sentinel als Proxy für Client-Verbindungen?

Nein. Sentinel ist nur eine Service-Discovery-Schicht. Clients fragen Sentinel nach der aktuellen Master-Adresse und verbinden sich dann direkt mit Redis. Es ist zwingend erforderlich, eine Sentinel-fähige Client-Bibliothek zu verwenden.

Wie verhindere ich Datenverlust durch Split-Brain in Redis Sentinel?

Konfigurieren Sie min-replicas-to-write und min-replicas-max-lag auf dem Master. Der Master lehnt dann Schreibbefehle ab, wenn weniger Replikate als erforderlich die Daten kürzlich bestätigt haben, und verhindert so, dass ein isolierter Master Schreibvorgänge akzeptiert, die nach dem Failover verloren gehen.