Cluster-Resharding ohne Downtime durchführen

1. Warum Resharding notwendig wird

Resharding beschreibt das nachträgliche Verschieben von Hash Slots zwischen den Knoten eines bestehenden Redis Cluster. Der Bedarf entsteht typischerweise aus drei Richtungen: Ein Teil des Datensatzes wächst schneller als andere und beansprucht überproportional viel Speicher auf seinem Knoten, neue Knoten mit mehr Kapazität werden hinzugefügt und sollen einen fairen Anteil der Last übernehmen, oder ein bestehender Knoten muss aus dem Cluster entfernt werden, etwa bei einer Hardware-Migration, und seine Slots müssen vorher anderweitig untergebracht werden.

Der entscheidende Unterschied zu einem klassischen Datenbank-Migrationsvorgang ist, dass Resharding in Redis Cluster ohne Downtime konzipiert ist. Während der Migration eines einzelnen Slots bleiben sowohl der Quell- als auch der Zielknoten für Lese- und Schreibzugriffe erreichbar, das Cluster-Protokoll über MOVED- und ASK-Redirects sorgt dafür, dass Clients transparent zum richtigen Knoten geleitet werden, selbst während sich Daten gerade in Bewegung befinden.

Wichtig zu verstehen ist, dass Resharding kein Ausnahmefall, sondern ein normaler, wiederkehrender Bestandteil des Betriebs eines wachsenden Redis Cluster ist. Teams, die Resharding als seltene, riskante Notoperation behandeln, statt es als Routineaufgabe zu etablieren, geraten regelmäßig unter unnötigen Zeitdruck, wenn ein Knoten tatsächlich an seine Kapazitätsgrenze stößt. Die folgenden Abschnitte zeigen, wie Resharding kontrolliert, überwacht und ohne Risiko für die Datenverfügbarkeit durchgeführt wird.

2. redis-cli --cluster reshard im Detail

Der Befehl redis-cli --cluster reshard ist das primäre Werkzeug für manuelles, gezieltes Resharding. Er fragt interaktiv nach der Anzahl zu verschiebender Slots, dem Zielknoten und den Quellknoten, und übernimmt anschließend die komplette Orchestrierung der Migration einzelner Slots inklusive aller notwendigen Zwischenschritte. Für automatisierte Abläufe lassen sich alle Parameter auch direkt als Kommandozeilenoptionen übergeben, ohne interaktive Eingabe.

Intern arbeitet --cluster reshard Slot für Slot ab: Für jeden zu migrierenden Slot ermittelt es zunächst alle darin enthaltenen Keys, versetzt den Slot auf Quell- und Zielknoten in den passenden Übergangszustand, und migriert die Keys einzeln über das MIGRATE-Kommando. Erst wenn alle Keys eines Slots erfolgreich migriert sind, wird der Slot final dem Zielknoten zugewiesen und die Cluster-Konfiguration über Gossip an alle anderen Knoten propagiert.

# Interactive reshard: move 500 slots to a specific target node
redis-cli --cluster reshard 10.0.2.10:7000

# Non-interactive reshard for scripting and automation
redis-cli --cluster reshard 10.0.2.10:7000 \
  --cluster-from abc123def456 \
  --cluster-to 789ghi012jkl \
  --cluster-slots 500 \
  --cluster-yes

# Move slots from multiple source nodes at once with "all"
redis-cli --cluster reshard 10.0.2.10:7000 \
  --cluster-to 789ghi012jkl \
  --cluster-slots 500 \
  --cluster-from all \
  --cluster-yes

Ein oft übersehener Parameter ist --cluster-timeout, der das Timeout für die interne MIGRATE-Operation pro Key steuert. Bei Keys mit sehr großen Werten, etwa umfangreichen Hashes oder Sorted Sets, kann der Standardwert zu knapp bemessen sein, was zu abgebrochenen Migrationen einzelner Keys führt. Für Cluster mit bekanntermaßen großen Einzelwerten sollte dieser Timeout bewusst erhöht werden, bevor ein Resharding-Vorgang gestartet wird.

3. Slot-Migration Schritt für Schritt: MIGRATING und IMPORTING

Der Kern jeder Slot-Migration in Redis Cluster sind zwei temporäre Zustände, die ein Slot während der Migration auf den beteiligten Knoten annimmt. Der Quellknoten markiert den Slot als MIGRATING, was bedeutet, dass dieser Knoten weiterhin Anfragen für bereits vorhandene Keys in diesem Slot bedient, aber bei Anfragen für Keys, die er nicht mehr besitzt, mit einem ASK-Redirect zum Zielknoten antwortet. Der Zielknoten markiert denselben Slot gleichzeitig als IMPORTING, akzeptiert aber nur Anfragen, denen ein ASKING-Kommando vorausgeht.

Diese Doppelmarkierung ist der Mechanismus, der Downtime während der Migration verhindert: Ein Client, der einen Key anfragt, der bereits migriert wurde, erhält vom Quellknoten einen ASK-Redirect, folgt diesem zum Zielknoten und erhält dort die korrekte Antwort. Erst wenn alle Keys eines Slots erfolgreich verschoben wurden, wird die Migration mit CLUSTER SETSLOT <slot> NODE <target-id> auf beiden Knoten final abgeschlossen, der MIGRATING- und IMPORTING-Zustand entfällt, und der Slot gehört ab diesem Zeitpunkt eindeutig dem Zielknoten.

# Manual low-level slot migration (what --cluster reshard automates)

# 1. Mark the slot as MIGRATING on the source node
redis-cli -p 7000 cluster setslot 12539 migrating 789ghi012jkl

# 2. Mark the same slot as IMPORTING on the target node
redis-cli -p 7003 cluster setslot 12539 importing abc123def456

# 3. Migrate every key in the slot individually
redis-cli -p 7000 cluster getkeysinslot 12539 100
redis-cli -p 7000 migrate 10.0.2.13 7003 "" 0 5000 keys \
  "order:9912" "order:9913" "order:9914"

# 4. Once all keys are moved, finalize slot ownership on both sides
redis-cli -p 7000 cluster setslot 12539 node 789ghi012jkl
redis-cli -p 7003 cluster setslot 12539 node 789ghi012jkl

Ein kritischer Punkt bei manueller Slot-Migration: Die finale CLUSTER SETSLOT ... NODE-Zuweisung muss auf allen betroffenen Knoten konsistent nachgezogen werden, nicht nur auf Quelle und Ziel, sonst entstehen widersprüchliche Sichten auf die Slot-Zuordnung im Cluster. Aus diesem Grund wird für Produktionsumgebungen fast immer redis-cli --cluster reshard statt manueller Einzelschritte empfohlen, da das Tool diese Konsistenz automatisch sicherstellt.

4. Knoten sicher hinzufügen

Einen neuen Knoten zu einem laufenden Redis Cluster hinzuzufügen erfolgt in zwei getrennten Schritten: Zuerst wird der neue Knoten über redis-cli --cluster add-node als leeres Cluster-Mitglied ohne zugewiesene Slots aufgenommen, danach folgt ein separater Resharding-Schritt, der ihm tatsächlich Slots und damit Daten zuweist. Diese Trennung ist bewusst: Sie erlaubt, den neuen Knoten zunächst als voll funktionsfähiges Cluster-Mitglied zu verifizieren, bevor Produktionsdaten auf ihn migriert werden.

Beim Hinzufügen eines Replica-Knotens statt eines Masters wird zusätzlich der Master angegeben, dem die neue Replica zugeordnet werden soll, über den Parameter --cluster-slave zusammen mit --cluster-master-id. Ohne explizite Angabe wählt Redis Cluster automatisch den Master mit den wenigsten bestehenden Replicas aus, was in den meisten Fällen sinnvoll ist, aber bei gezielter Kapazitätsplanung explizit überschrieben werden sollte.

# Step 1: join a new empty master node to the running cluster
redis-cli --cluster add-node 10.0.2.16:7006 10.0.2.10:7000

# Step 1b: join a new replica node, attached to a specific master
redis-cli --cluster add-node 10.0.2.17:7007 10.0.2.10:7000 \
  --cluster-slave \
  --cluster-master-id abc123def456

# Step 2: verify the new node joined with zero slots assigned
redis-cli -c -p 7006 cluster nodes | grep myself

# Step 3: reshard slots onto the new master to give it real capacity
redis-cli --cluster reshard 10.0.2.10:7000 \
  --cluster-to <new-node-id> \
  --cluster-slots 2730 \
  --cluster-from all \
  --cluster-yes

Ein häufiger Fehler ist, den neuen Knoten sofort mit einem großen Anteil an Slots zu bestücken, statt schrittweise vorzugehen. Bei einer stufenweisen Migration, etwa in mehreren Tranchen von jeweils wenigen hundert Slots über mehrere Stunden verteilt, lässt sich die Auswirkung auf CPU- und Netzwerklast des neuen Knotens beobachten und bei Problemen frühzeitig stoppen, bevor der gesamte geplante Slot-Anteil migriert wurde.

5. Knoten sicher entfernen

Bevor ein Master-Knoten aus einem Redis Cluster entfernt werden kann, müssen zwingend alle seine Slots auf andere Knoten migriert werden, ein Cluster akzeptiert das Entfernen eines Masters mit noch zugewiesenen Slots nicht. Der Ablauf ist deshalb immer: erst per --cluster reshard alle Slots des zu entfernenden Knotens auf verbleibende Knoten verteilen, dann erst redis-cli --cluster del-node zum tatsächlichen Entfernen aus dem Cluster verwenden.

Beim Entfernen eines Replica-Knotens entfällt der Reshard-Schritt, da Replicas keine eigenen Slots besitzen, sie können direkt per del-node entfernt werden. Wichtig ist dabei nur, sicherzustellen, dass der zugehörige Master danach noch über eine ausreichende Anzahl verbleibender Replicas für Failover-Sicherheit verfügt, bevor eine Replica dauerhaft aus dem Cluster genommen wird.

# Step 1: move all slots away from the node being decommissioned
redis-cli --cluster reshard 10.0.2.10:7000 \
  --cluster-from <node-to-remove-id> \
  --cluster-to <remaining-node-id> \
  --cluster-slots 5461 \
  --cluster-yes

# Step 2: verify the node now owns zero slots
redis-cli -c -p 7002 cluster nodes | grep <node-to-remove-id>

# Step 3: remove the now-empty node from the cluster
redis-cli --cluster del-node 10.0.2.10:7000 <node-to-remove-id>

# Removing a replica is simpler: no slots to migrate first
redis-cli --cluster del-node 10.0.2.10:7000 <replica-node-id>

Ein Sicherheitsnetz, das sich in der Praxis bewährt hat: Vor dem finalen del-node sollte redis-cli --cluster check gegen das Cluster laufen, um zu bestätigen, dass cluster_state:ok gilt und alle 16384 Slots weiterhin korrekt zugewiesen sind. Erst nach dieser Bestätigung sollte der zu entfernende Knoten tatsächlich heruntergefahren werden, nicht vorher.

6. Automatisiertes Resharding und Rebalancing

Neben dem gezielten --cluster reshard bietet redis-cli --cluster rebalance eine automatisierte Alternative, die die Slot-Verteilung über alle Master-Knoten hinweg neu berechnet und ausgleicht, ohne dass für jeden einzelnen Slot-Block manuell Quelle und Ziel angegeben werden müssen. Das Tool berücksichtigt dabei optional unterschiedliche Kapazitätsgewichte pro Knoten über --cluster-weight, was bei heterogener Hardware im Cluster relevant ist.

Der Parameter --cluster-use-empty-masters ist besonders beim Hinzufügen mehrerer neuer Knoten gleichzeitig nützlich, da rebalance standardmäßig Master ohne jegliche Slots von der automatischen Verteilung ausschließt, aus Sicherheitsgründen, um versehentliches Umverteilen auf noch nicht vollständig eingerichtete Knoten zu verhindern. Wer bewusst neue, leere Master in die Verteilung einbeziehen will, muss dieses Flag also explizit setzen.

# Automatic rebalance including newly added empty master nodes
redis-cli --cluster rebalance 10.0.2.10:7000 \
  --cluster-use-empty-masters

# Rebalance with a maximum threshold to avoid over-correcting
# (only rebalance nodes deviating more than 5% from the target)
redis-cli --cluster rebalance 10.0.2.10:7000 \
  --cluster-threshold 5

# Always simulate first to review the planned moves
redis-cli --cluster rebalance 10.0.2.10:7000 \
  --cluster-simulate \
  --cluster-use-empty-masters

Der Parameter --cluster-threshold verhindert unnötiges Resharding bei bereits nahezu ausgeglichener Verteilung: Nur Knoten, deren Slot-Anteil um mehr als den angegebenen Prozentwert vom idealen Zielwert abweicht, werden überhaupt neu ausbalanciert. Das reduziert die Anzahl unnötiger Slot-Migrationen erheblich und ist besonders in großen Clustern mit vielen Knoten spürbar, wo eine vollständige Neuverteilung ohne Schwellenwert unverhältnismäßig viel Datenverkehr erzeugen würde.

7. Downtime-Risiken erkennen und vermeiden

Obwohl Resharding in Redis Cluster grundsätzlich ohne Downtime konzipiert ist, gibt es reale Risiken, die zu spürbaren Verzögerungen oder in Extremfällen zu kurzzeitiger Nichtverfügbarkeit führen können. Das größte Risiko sind sehr große Einzelkeys: Die MIGRATE-Operation blockiert den Quellknoten für die Dauer der Übertragung eines einzelnen Keys, bei einem mehrere hundert Megabyte großen Hash oder Sorted Set kann das spürbare Latenz für alle anderen Clients erzeugen, die währenddessen denselben Knoten anfragen.

Ein zweites Risiko betrifft die Netzwerkbandbreite zwischen den beteiligten Knoten während großvolumiger Resharding-Vorgänge. Wird zu viel Slot-Migration gleichzeitig gestartet, etwa alle Slots eines zu entfernenden Knotens in einem einzigen großen Batch, kann das die verfügbare Bandbreite für normalen Anwendungstraffic zwischen den Knoten deutlich reduzieren. Die Lösung ist, Resharding in kleineren Tranchen mit Pausen dazwischen durchzuführen, statt alles in einem einzigen Durchlauf zu migrieren.

# Reshard in smaller batches with pauses to limit impact
for i in $(seq 1 10); do
  redis-cli --cluster reshard 10.0.2.10:7000 \
    --cluster-from <node-to-remove-id> \
    --cluster-to <target-node-id> \
    --cluster-slots 500 \
    --cluster-yes
  sleep 30   # let the cluster settle before the next batch
done

# Identify unusually large keys before resharding a node
redis-cli -p 7000 --bigkeys

# Increase the per-key migrate timeout for known large values
redis-cli --cluster reshard 10.0.2.10:7000 \
  --cluster-timeout 15000 \
  --cluster-slots 500 --cluster-yes

Für Cluster mit bekannten großen Einzelwerten empfiehlt sich außerdem, diese Keys vorab zu identifizieren und gezielt einzeln zu migrieren, statt sie im automatisierten Batch-Vorgang von --cluster reshard überraschend anzutreffen. redis-cli --bigkeys liefert dafür eine schnelle Übersicht über ungewöhnlich große Keys im Datensatz, bevor ein Resharding-Vorgang überhaupt gestartet wird.

8. Monitoring während des Resharding-Vorgangs

Während eines laufenden Resharding-Vorgangs sollten mehrere Kennzahlen parallel beobachtet werden, um Probleme frühzeitig zu erkennen, statt sie erst nach Abschluss der Migration zu bemerken. CLUSTER INFO zeigt kontinuierlich den Gesamtzustand des Clusters, CLUSTER NODES die aktuelle Slot-Zuordnung pro Knoten, und die Latenz-Statistiken aus INFO commandstats zeigen, ob die MIGRATE-Operationen spürbaren Einfluss auf die allgemeine Antwortzeit des Clusters haben.

Ein besonders nützlicher Befehl während laufender Migrationen ist redis-cli --cluster check <any-node>, der explizit prüft, ob noch Slots im MIGRATING- oder IMPORTING-Zwischenzustand hängen geblieben sind, etwa weil ein Resharding-Vorgang unterbrochen wurde. Solche hängen gebliebenen Zustände sollten nicht ignoriert werden, sie können zu inkonsistentem Client-Verhalten führen, wenn ältere Client-Bibliotheken mit ASK-Redirects nicht korrekt umgehen.

9. Rollback-Strategien bei fehlgeschlagenem Resharding

Bricht ein Resharding-Vorgang unerwartet ab, etwa durch einen Netzwerkfehler oder einen abgestürzten Knoten während der Migration, bleiben betroffene Slots im MIGRATING- beziehungsweise IMPORTING-Zustand hängen. In diesem Zustand funktioniert das Cluster für die meisten Zugriffe weiter normal, dank der ASK-Redirect-Logik, aber der Zustand sollte möglichst zeitnah aufgelöst werden, um weitere Inkonsistenzen zu vermeiden.

Die sicherste Rollback-Strategie ist, den unterbrochenen Migrationsvorgang schlicht fortzusetzen, statt ihn rückgängig zu machen: Da jeder Key einzeln migriert wird, sind bereits übertragene Keys bereits sicher auf dem Zielknoten, ein erneuter Aufruf von redis-cli --cluster fix erkennt hängen gebliebene Slots und schließt die Migration der verbleibenden Keys automatisch ab, statt bereits migrierte Daten zurückzuschieben.

# Detect and automatically resolve stuck slot migrations
redis-cli --cluster fix 10.0.2.10:7000

# Manual inspection before running fix, to understand the scope
redis-cli -c -p 7000 cluster nodes | grep -E "migrating|importing"

# If a node is unreachable and blocking the fix, verify its
# last known state before forcing slot ownership decisions
redis-cli -c -p 7003 cluster info | grep cluster_state

# After fix completes, always re-verify full slot coverage
redis-cli --cluster check 10.0.2.10:7000

Ein echtes Zurückrollen auf den Zustand vor der Migration ist in Redis Cluster architektonisch nicht vorgesehen und sollte auch nicht angestrebt werden, da es das Risiko von Dateninkonsistenzen erhöht statt reduziert. Die robustere Strategie ist immer, vorwärts zu reparieren, mit --cluster fix, statt rückwärts zurückzurollen, kombiniert mit ausreichenden Backups des Gesamtdatensatzes vor Beginn eines größeren Resharding-Vorhabens als letzte Absicherung.

10. Zusammenfassung

Cluster-Resharding ohne Downtime ist in Redis Cluster kein Sonderfall, sondern ein fest eingebauter, wiederkehrender Betriebsvorgang, der über den MIGRATING/IMPORTING-Zustand einzelner Slots und die ASK-Redirect-Logik verfügbar bleibt, während Daten sich noch in Bewegung befinden. redis-cli --cluster reshard automatisiert diesen Vorgang für gezielte Verschiebungen, --cluster rebalance für automatische Neuverteilung, beide bauen auf denselben grundlegenden Mechanismen auf.

Die wichtigsten praktischen Regeln sind: Resharding in kleinen Tranchen statt einem großen Batch durchführen, große Einzelkeys vorab identifizieren und deren Timeout-Anforderungen berücksichtigen, kontinuierlich mit cluster info und --cluster check überwachen, und bei einem unterbrochenen Vorgang immer mit --cluster fix vorwärts reparieren statt zurückzurollen. Wer diese Regeln befolgt, kann Redis Cluster über Jahre hinweg wachsen und schrumpfen lassen, ohne jemals ein Wartungsfenster für die Datenumverteilung selbst zu benötigen.

11. FAQ: Cluster-Resharding ohne Downtime