Von Redis 7.2 auf Valkey migrieren: ohne Downtime mit REPLICAOF

30.07.2026

Valkey hängt sich als Replica an dein Redis 7.2 und übernimmt beim Cutover. Kein Dump, kein Wartungsfenster, ein Befehl.

Inhaltsverzeichnis

Warum überhaupt wechseln

Im März 2024 hat Redis die Lizenz gewechselt. Weg von BSD-3-Clause, also echtem Open Source, hin zu einer Doppellizenz aus der Redis Source Available License und der Server Side Public License. Keine der beiden ist von der Open Source Initiative anerkannt.

Die letzte Version unter BSD ist 7.2.4. Alles ab 7.4 fällt unter die neuen Bedingungen.

Wenige Tage nach der Ankündigung hat die Linux Foundation Valkey vorgestellt: einen Fork, abgespalten an genau dieser Version 7.2.4, weiter unter BSD-3-Clause. Getragen von einer Stiftung statt von einem einzelnen Unternehmen. Es ist dieselbe Frage wie bei Terraform und OpenTofu: nicht nur, welche Lizenz gilt, sondern wer sie jederzeit ändern kann.

Wenn du heute auf Redis 7.2 sitzt, hast du deshalb eine Entscheidung vor dir. Und der angenehme Teil daran ist: Der Weg zu Valkey ist kein Migrationsprojekt. Er ist ein Befehl.

Was du brauchst

Eine laufende Redis-Instanz der Version 7.2 oder älter und Platz für eine zweite Instanz daneben, für die Dauer der Migration.

Das ist die eine Voraussetzung, die wirklich zählt: Ab Redis 7.4 funktioniert dieser Weg nicht mehr. Wenn du bereits auf 7.4 oder neuer bist, brauchst du einen anderen Ansatz. Warum das so ist, hat einen eigenen Beitrag verdient, den ich nachreiche.

Prüf also zuerst, wo du stehst:

redis-cli INFO server | grep redis_version

redis_version:7.2.15

Alle folgenden Befehle habe ich mit Valkey 9.1.1 gegen Redis 7.2.15 durchgespielt. Ich zeige sie als reine redis-cli- und valkey-cli-Aufrufe, damit sie überall funktionieren. In Kubernetes packst du dasselbe in ein kubectl exec, weiter unten steht ein Beispiel.

Das Prinzip: Replikation statt Dump

Der naheliegende Weg wäre, die Daten zu exportieren und wieder einzuspielen. Genau den brauchst du nicht.

Valkey stammt aus derselben Codebasis und spricht dasselbe Replikationsprotokoll wie Redis. Du kannst eine Valkey-Instanz deshalb als ganz normale Replica an dein laufendes Redis hängen. Sie zieht sich den Datenbestand, bleibt danach im Takt und übernimmt auf Kommando die Rolle des Masters.

Der Ablauf in vier Schritten:

  1. Valkey daneben stellen, leer
  2. Valkey per REPLICAOF an das laufende Redis hängen
  3. warten, bis der Sync steht, und das auch nachprüfen
  4. Valkey aus der Replikation lösen und die Clients umschwenken

Während der ersten drei Schritte läuft dein Redis normal weiter. Erst Schritt 4 verändert etwas, und der dauert Sekunden.

Schritt 1: Valkey daneben stellen

Die Instanz startet leer, ohne Konfiguration, ohne Daten:

docker run -d --name valkey -p 6380:6379 valkey/valkey:9.1.1-alpine

Ein Blick auf die neue Instanz lohnt sich, weil er gleich erklärt, warum die Replikation überhaupt funktioniert:

valkey-cli -p 6380 INFO server | grep -E "server_name|version"

server_name:valkey
valkey_version:9.1.1
redis_version:7.2.4

Drei Zeilen, und die dritte ist die interessante. Valkey ist längst bei Version 9, meldet aber weiterhin redis_version:7.2.4, also exakt den Punkt, an dem der Fork abgezweigt ist. Das ist keine Nostalgie, sondern die Kompatibilitätsangabe, an der sich Clients und eben auch die Replikation orientieren.

Schritt 2: die Replikation starten

Ein Befehl, abgesetzt auf der Valkey-Seite:

valkey-cli -p 6380 REPLICAOF <redis-host> 6379

OK

Und hier die erste Stelle, an der man sich täuschen lassen kann: Dieses OK bedeutet nur, dass Valkey den Auftrag angenommen hat. Es sagt nichts darüber, ob der Sync auch zustande kommt. Der läuft danach asynchron im Hintergrund.

Schritt 3: prüfen, dass es wirklich läuft

Deshalb wird jetzt nachgesehen, und zwar an zwei Stellen.

Erstens der Status der Replikation:

valkey-cli -p 6380 INFO replication

role:slave
master_link_status:up

role:slave heißt, die Rolle ist gesetzt. Entscheidend ist die zweite Zeile: master_link_status:up bedeutet, dass die Verbindung wirklich steht und der Datenbestand übertragen wurde. Steht dort down, hast du kein Netzwerkproblem übersehen, sondern gar keine Replikation.

Zweitens die Gegenprobe mit echten Daten. Schreib auf der Redis-Seite und lies auf der Valkey-Seite:

redis-cli SET migration:test "läuft"
valkey-cli -p 6380 GET migration:test

"läuft"

Damit weißt du nicht nur, dass der Erstabgleich geklappt hat, sondern dass auch laufende Änderungen ankommen. Genau das trägt den Cutover ohne Downtime.

Nimm dir hier ruhig Zeit. Solange Valkey Replica ist, kostet dich Warten nichts, und dein Redis läuft unverändert weiter. Ein guter Moment, um die Anwendung testweise gegen den Valkey-Port lesen zu lassen.

Schritt 4: der Cutover

Wenn du zufrieden bist, löst du Valkey aus der Replikation:

valkey-cli -p 6380 REPLICAOF NO ONE

OK

Ab diesem Moment ist Valkey ein eigenständiger Master mit dem vollständigen Datenbestand und nimmt Schreibzugriffe an. Jetzt schwenkst du deine Anwendung um, per Service, per Verbindungszeichenfolge oder per DNS, je nachdem wie deine Umgebung aussieht.

Deine Clients brauchen dafür nichts. Das Protokoll ist dasselbe, die Bibliotheken bleiben, der Code bleibt.

Das alte Redis lässt du danach noch eine Weile laufen. Es kostet wenig und ist dein Rückweg, solange du ihn brauchst.

Derselbe Ablauf in Kubernetes

Wenn beide als StatefulSet laufen, ändert sich nur die Verpackung. Der headless Service liefert dir den stabilen Namen, den REPLICAOF braucht:

kubectl exec valkey-0 -- valkey-cli REPLICAOF redis-0.redis 6379
kubectl exec valkey-0 -- valkey-cli INFO replication
kubectl exec valkey-0 -- valkey-cli REPLICAOF NO ONE

Wichtig ist der Name redis-0.redis: erster Teil der Pod-Name, zweiter Teil der Service-Name. Einen normalen Service mit ClusterIP kannst du hier nicht nehmen, weil die Replikation einen konkreten Knoten adressieren muss und keinen Lastverteiler. Genau dafür ist der headless Service da.

Was du danach prüfen solltest

Konfiguration. Die Replikation überträgt Daten, keine Einstellungen. Speicherlimits, Eviction-Strategie, Persistenz und Passwörter musst du auf der Valkey-Seite selbst setzen, bevor du umschwenkst.

Authentifizierung. Ist dein Redis passwortgeschützt, braucht Valkey vor dem REPLICAOF ein CONFIG SET masterauth <passwort>, sonst bleibt master_link_status auf down.

Mehrere Knoten. Bei einem Setup mit Sentinel oder mehreren Replicas ist die Reihenfolge die eigentliche Arbeit: erst die Sentinels, dann die Replicas, dann ein Failover, und der bisherige Master zuletzt. Das Prinzip bleibt dasselbe, nur die Choreografie wird länger.

Monitoring. Exporter und Dashboards fragen oft nach redis_version. Da Valkey weiterhin 7.2.4 meldet, funktionieren die meisten davon unverändert. Prüf es trotzdem, bevor du das alte Redis abschaltest.

Fazit

  1. Die letzte Redis-Version unter offener Lizenz ist 7.2.4, Valkey führt genau diesen Stand unter BSD weiter, getragen von der Linux Foundation.
  2. Der Wechsel läuft über Replikation, nicht über Export und Import: Valkey als Replica anhängen, synchronisieren lassen, mit REPLICAOF NO ONE lösen.
  3. Das OK nach REPLICAOF beweist nichts. Erst master_link_status:up und ein echter Lesetest zeigen, dass der Sync steht.
  4. In Kubernetes brauchst du einen headless Service, damit REPLICAOF einen einzelnen Knoten adressieren kann.
  5. Konfiguration, Passwörter und Monitoring wandern nicht mit. Die stellst du vorher ein.

Der wichtigste Satz zum Schluss ist aber der vom Anfang: Dieser Weg setzt Redis 7.2 als Quelle voraus. Ab 7.4 steht er nicht mehr offen. Wer die Wahl behalten will, trifft sie also besser früher als später, und genau darum geht es hier immer: die eigene Plattform verstehen, solange man noch entscheiden kann.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.