Ein Image-Tag, und der Rückweg ist zu

In einem Pull Request steht folgende Zeile: aus redis:7.2.4 wird redis:7.4. Ein Bot hat sie vorgeschlagen, ein Mensch hat durchgewinkt, die Pipeline war grün. Alltag.

In dieser einen Zeile stecken zwei Entscheidungen, die niemand bewusst getroffen hat. Die erste ist bekannt: Ab 7.4 ist Redis kein Open Source mehr im Sinne der OSI. Die zweite kennt fast niemand: Der Rückweg ist zu. Nicht schwierig, nicht teuer. Zu.

Denn Redis 7.4 hebt das RDB-Format von Version 11 auf 12. Beim ersten Speichern wird der Snapshot auf dem PersistentVolume neu geschrieben, und danach startet ein Redis 7.2 auf demselben Volume nicht mehr:

# Can't handle RDB format version 12
# Fatal error loading the DB, check server logs. Exiting.

Der Rollback holt das Image zurück, nicht die Daten.

Das ist die Stelle, an der auch kubectl rollout undo nicht mehr hilft. Bei GitOps ist der Commit zurückgenommen, das Volume nicht. Und es ist kein Laborfall: Genau das ist Argo CD passiert, als ein Chart das mitgelieferte Redis von 7.4.2 auf 7.2.8 zurückstufte.

Im neuen Video zeige ich beides. Erstens, warum das Format überhaupt bricht, und zwar Byte für Byte an einem einzelnen Eintrag: Erst kommt der Typ, dann die Länge. Wer den Typ nicht kennt, weiß nicht, wie weit er springen müsste, deshalb ist Überspringen keine Option. Zweitens den Ausweg per REPLICAOF, ohne Downtime, samt der vollständigen Matrix aus neun gemessenen Replikations-Kombinationen.

Video ansehen →

Die Kurzfassung der Matrix: Valkey als Master repliziert zu Redis zurück, auch zu 7.4. Redis 7.4 als Master repliziert zu Valkey nicht. Der Fork hat die Kompatibilität behalten, das Original hat sie aufgegeben.

Zum Ausdrucken und Weitergeben: Lizenz-Zeitleiste, Diagnose in drei Befehlen, die vollständige Matrix und der Cutover-Ablauf, als Spickzettel im PDF-Format, fünf Seiten, auch fürs Team.

Lieber lesen als schauen? Den technischen Kern habe ich auch als Beitrag aufgeschrieben, inklusive der Frage, was appendonly yes daran ändert. Kurz gesagt: Es verzögert das Problem, es löst es nicht.

Der Satz, der davon bleibt, gilt nicht nur für Datenbanken: Entschieden wird das nicht bei der Migration. Entschieden wird es beim ersten Befehl, den es auf der anderen Seite nicht gibt.

Bis nächste Woche,
Christian