> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2025/w46-database-migration-case-study.md).

# W46-Fallstudie einer Datenbankmigration

Ich las einen Erfahrungsbericht zur Datenbankmigration: [Wie wir eine Milliarde Datensätze ohne Ausfall von DB1 nach DB2 migrierten](https://medium.com/@himanshusingour7/how-we-migrated-db-1-to-db-2-1-billion-records-without-downtime-c034ce85d889). Er beschreibt die Migration eines Finanzdatenbankclusters mit einer Milliarde Datensätzen ohne Stillstand.

Vieles passt zu unseren Grundideen technischer Risikokontrolle. Risiken werden schrittweise kontrolliert, jeder Schritt ist unabhängig prüfbar und rückgängig zu machen. Beobachtbarkeit steht an erster Stelle. Von WAL-Logs und Cachetrefferquoten bis zu Bestellungen und Erlösströmen hilft durchgängiges Monitoring, Abweichungen rechtzeitig zu erkennen. Ein besonders geschicktes Verfahren für Datenbank- und Backend-Migrationen ist mir dabei aufgefallen: Shadow Reads.

Datenmigration ist im Kern eine komplexe Systementwurfsaufgabe. Der Autor beschreibt fünf wichtige Entscheidungen.

Erstens werden kalte Daten mithilfe von Sharding, paralleler Verarbeitung und abgeschalteten Indizes in großen Mengen übertragen.

Zweitens synchronisieren doppelte Schreibvorgänge und eine Kafka-Wiederholungswarteschlange den laufenden Traffic zwischen alter und neuer Datenbank. Dabei bleibt Idempotenz gewahrt.

Drittens prüfen Shadow Reads die Daten im laufenden Betrieb. Nutzeranfragen lesen weiter aus der alten Datenbank. Jede Abfrage wird aber im Hintergrund auch auf der neuen ausgeführt, und die Ergebnisse werden verglichen. Über mehrere Wochen fanden sie so viele Probleme, die eine Testumgebung nie gezeigt hätte: unterschiedliche Zeitzonenbehandlung, Standardverhalten bei NULL und abweichende Sortierregeln. Später fiel mir ein, dass die Backend-Migration unseres Checkouts vergangenes Jahr wohl ähnlich vorging. Im Frontend lässt sich das schwer wiederholen.

Viertens erfolgt der vorsichtige Wechsel bei wenig Traffic. Vorgewärmte Caches, Rollbackplan und enges Monitoring sichern den Übergang.

Zuletzt betont der Autor die Bedeutung starker Beobachtbarkeit während der gesamten Migration.

Im Frontend sind Shadow Reads schwierig, weil jeder Nutzer jeweils nur eine Version besucht. Wer die neue sieht, sieht nicht gleichzeitig die alte. In Datenbanken lassen sich Ergebnismengen unsichtbar vergleichen. Korrektheit im Frontend ist viel komplexer als Datenkonsistenz. Sie umfasst Interaktion, Performance, Barrierefreiheit und Gerätekompatibilität. Für all das fehlen günstige Prüfverfahren. Schrittweise Trafficfreigabe, Analyse des Nutzerverhaltens, Geschäftskennzahlen und manuelle Prüfungen bleiben die wirksamsten Mittel.