Redis / Valkey: täglicher Betrieb und Störungsszenarien (Cluster und Sentinel)

Keine Installation: ein szenariobasiertes Runbook, um einen installierten Redis Cluster oder einen von Sentinel verwalteten Master/Replica-Aufbau im Alltag zu betreiben und bei Störungen wiederherzustellen (Redis 7.2, Redis 8 und Valkey). Cluster: Health Check, Nodes hinzufügen/entfernen, Rebalance/Reshard, manueller Failover (FORCE vs. TAKEOVER), Austausch eines ausgefallenen Node und --cluster fix. Sentinel: Status und Quorum, SENTINEL FAILOVER, Nodes hinzufügen/entfernen und SENTINEL RESET, Änderung von Einstellungen. Für beide: Speicherdruck und Diagnose großer/heißer Keys. Weißt du nicht genau, was zu tun ist, beginne mit dem Health Check; Wiederherstellung aus dem Backup und Security-Härtung behandeln eigene Redis-Guides.

Topologie: Redis Cluster (3+ Master + Replicas) oder Sentinel (1 Master + Replicas + 3 Sentinels)

Szenarien

• Cluster-Health-Check (--cluster check, CLUSTER INFO / NODES) — Nur lesend: Sind alle Slots abgedeckt, stimmen die Nodes in der Konfiguration überein, gibt es einen ausgefallenen Node (fail) oder einen Master ohne Replica? Beginne hier, wenn du nicht sicher bist, was zu tun ist.
• Node zum Cluster hinzufügen (Master oder Replica) — Eine neue Instanz (cluster-enabled yes, leer) ist bereit: Sie tritt dem Cluster als Master bei und erhält Slots oder wird Replica eines Masters. Keine Downtime.
• Node aus dem Cluster entfernen (Slots leeren + del-node) — Ein Master oder Replica wird außer Betrieb genommen: Die Slots des Masters werden auf die anderen Master verschoben, danach wird der Node aus dem Cluster entfernt. Keine Downtime; während der Migration treten ASK-Umleitungen auf.
• Slots neu verteilen (Rebalance / Reshard) — Slots oder Speicher sind zwischen den Mastern ungleich verteilt, ein neuer Master hat keine Slots erhalten, oder eine bestimmte Anzahl Slots soll von einem Master auf einen anderen verschoben werden.
• Manueller Failover: Replica zum Master machen (CLUSTER FAILOVER, FORCE, TAKEOVER) — Auf dem Server des Masters steht Wartung an (geplant, kein Datenverlust), oder der Master ist nicht erreichbar und es kam kein automatischer Failover zustande (FORCE / TAKEOVER; Risiko von Datenverlust).
• Ausgefallenen Master / Node ersetzen (FORGET, neue Replica, --cluster fix) — Der Server eines Node ist dauerhaft verloren: Ist seine Replica Master geworden, wird der alte Node vergessen und an seiner Stelle eine neue Replica hinzugefügt; hatte er keine Replica, bleiben seine Slots ohne Besitzer und werden mit --cluster fix geschlossen (die Daten in diesen Slots sind verloren).
• Sentinel-Status: Master, Replicas, Sentinels, Quorum — Nur lesend: die Master-Adresse, die die Sentinels sehen, die Replicas, die anderen Sentinels, CKQUORUM und die letzten Failover-Ereignisse. Beginne hier, wenn du in einem Sentinel-Aufbau nicht sicher bist, was zu tun ist.
• Manueller Failover mit Sentinel (SENTINEL FAILOVER) — Auf dem Server des Masters steht Wartung an: Sentinel macht die geeignetste Replica zum Master und richtet die übrigen Replicas und die Clients auf den neuen Master aus. Unterbrechung 1–2 s; kein Datenverlust, solange der Master läuft.
• Node im Sentinel-Aufbau hinzufügen / entfernen / ersetzen (SENTINEL RESET) — Eine Replica oder ein Sentinel wurde dauerhaft entfernt oder neu hinzugefügt: Die neue Replica verbindet sich mit REPLICAOF, veraltete Einträge der Sentinels werden mit SENTINEL RESET bereinigt.
• Quorum und Sentinel-Einstellungen ändern (SENTINEL SET) — Die Zahl der Sentinels hat sich geändert, oder der Failover löst zu spät/zu früh aus: quorum, down-after-milliseconds, failover-timeout und parallel-syncs werden auf allen Sentinels geändert.
• Speicherdruck: Diagnose von Belegung, Fragmentierung, Eviction — used_memory nähert sich maxmemory, Fehler 'OOM command not allowed', Eviction nimmt zu, RSS ist größer als erwartet, oder die Replica-/AOF-Puffer sind angewachsen. Die Diagnose ist nur lesend; die Abhilfen werden separat beschrieben.
• Große und heiße Keys finden (--bigkeys, --memkeys, --hotkeys) — Speicher oder CPU eines Node liegen höher als bei den anderen, es gibt Latenzspitzen, DEL dauert lange: Die größten und am häufigsten abgerufenen Keys werden ermittelt und sicher bereinigt (UNLINK).

Vor dem Start

• Auf dem Administrationsserver ist … installiert (kommt mit …, /usr/bin/…) und erreicht …die Instanz ……alle Cluster-Nodes sowohl über den Client-Port als auch über den Cluster-Bus-Port (Port + 10000)…die Sentinels (…) und Redis (…)….
• Du hast das Passwort von … (requirepass / masterauth); es wird in den Schritten abgefragt oder aus der Umgebungsvariable REDIS_PASS gelesen. Verwendest du ACLs, braucht der Benutzer +@admin (Cluster-/Sentinel-Befehle) und +@keyspace.
• Ein Change-Eintrag ist angelegt, das Anwendungsteam ist informiert. Failover und Slot-Migration können bei den Clients kurze MOVED/ASK-Umleitungen oder Verbindungsabbrüche verursachen; cluster-fähige (cluster-aware) Clients folgen diesen von selbst.
• Die neue Instanz … ist wie im Redis-Cluster-Installations-Guide bereit: gleiche …-Version, cluster-enabled yes, gleiches requirepass/masterauth, leeres Datenverzeichnis (keine alte nodes-.conf, kein RDB/AOF), Client- und Bus-Port (Port + 10000) in der Firewall offen.

Phasen der Anleitung

• Status: Slot-Abdeckung, Nodes und Konfigurationskonsistenz (nur lesend) — Cluster prüfen (--cluster check) · Nodes, Rollen und Replica-Verteilung anzeigen · Ergebnis auswerten
• 1. Diagnose: Ist der neue Node leer und erreichbar? — Neuen Node und Cluster prüfen
• 2. Anwenden: Node hinzufügen — Node zum Cluster hinzufügen (--cluster add-node) · Slots auf den neuen Master verteilen (Rebalance) · Replica für den neuen Master einplanen
• 3. Prüfung — Cluster und neuen Node prüfen
• 1. Diagnose: Ist der Node ein Master, hat er Slots? — Rolle und Slots des zu entfernenden Node anzeigen
• 2. Anwenden: Slots leeren und Node entfernen — Slots des Masters auf die anderen Master verschieben · Node aus dem Cluster entfernen (--cluster del-node) · Dienst auf dem entfernten Server deaktivieren
• 3. Prüfung — Cluster prüfen
• 1. Diagnose: aktuelle Verteilung — Slots, Keys und Speicher pro Master
• 2. Anwenden — …Slots ausgleichen (Rebalance)…… Slots verschieben (Reshard)…
• 1. Diagnose — Rolle und Master-Verbindung der Replica anzeigen
• 2. Anwenden — Failover starten (CLUSTER FAILOVER… FORCE… TAKEOVER…)
• 3. Prüfung — Neuen Aufbau prüfen
• 1. Diagnose: verlorener Node und Slot-Abdeckung — Nodes im Zustand fail und Slots ohne Besitzer anzeigen
• 2. Anwenden: verlorenen Node vergessen — Verlorenen Node von allen Nodes vergessen lassen (CLUSTER FORGET) · Slots ohne Besitzer schließen (--cluster fix) · Neuen Node als Replica hinzufügen
• 3. Prüfung und Nacharbeiten — Cluster prüfen
• Status: Master, Replicas, Sentinels (nur lesend) — Master und Quorum aus Sicht des Sentinel · Replicas und andere Sentinels auflisten · Sentinel-Log nach den letzten Failover-Ereignissen durchsuchen
• 1. Diagnose — Prüfen, dass Quorum und Replicas bereit sind
• 2. Anwenden — Failover starten (SENTINEL FAILOVER)
• 3. Prüfung — Neuen Master und Replicas prüfen
• 1. Diagnose — Den Sentinels bekannte Anzahl von Replicas und Sentinels
• 2. Anwenden — Neue Replica an den Master hängen · Dienst der entfernten Replica herunterfahren · Neuen Sentinel starten · Entfernten Sentinel herunterfahren · SENTINEL RESET auf allen Sentinels
• 3. Prüfung — Zahlen und Quorum erneut prüfen
• 1. Diagnose — Aktuelle Einstellungen auf jedem Sentinel anzeigen
• 2. Anwenden — … auf allen Sentinels auf … setzen
• 1. Diagnose: Speicher, Limit und Eviction — Speicherbelegung und Limit anzeigen (INFO memory) · MEMORY DOCTOR und MEMORY STATS · Speichereinstellungen anzeigen
• 2. Abhilfen — Abhilfe je nach Lage
• 1. Diagnose: große und heiße Keys — Größte Keys pro Typ (--bigkeys) · Größte Keys nach Speicher (--memkeys) · Heiße Keys (--hotkeys) · Größe und Typ eines Keys untersuchen
• 2. Abhilfe — Großen Key sicher löschen (UNLINK)