Datenmigration
Datenmigration verändert Schema oder Datenbestand, während Softwareversionen und Zugriffe übergangsweise parallel bestehen können. Erweiterung, Befüllung und spätere Umstellung ordnen diesen Übergang.
- Schritt für SchrittKleine kompatible Änderungen statt eines großen Sprungs.
- Parallele VersionenAlt und neu laufen zeitgleich.
- Zu früh verpflichtendEine Pflichtspalte vor dem Befüllen bricht Versionen.
Einordnung
Warum das wichtig ist
Während eines Rollouts laufen alte und neue Version gleichzeitig. Setzt die neue Version ein Feld voraus, das die alte nicht schreibt, entstehen Lücken oder Ausfälle. Kleine kompatible Schritte vermeiden das.
Dieser Baustein behandelt Daten- und Schemaübergänge. Deployment koordiniert Versionen; Recovery prüft Wiederherstellung eines Datenstands.
Auf einen Blick · Migration in vier Phasen
Rechnungskennung: Welche App-Version läuft in welcher Phase
Der Shop ergänzt eine Rechnungskennung für Bestellungen. Zuerst wird die Spalte optional angelegt, danach durch die Anwendung befüllt und erst später verpflichtend gelesen.
So liest du das Bild
- Schritt für Schritt Du gehst vier Phasen durch; in den Phasen 1 bis 3 laufen beide Versionen ohne Fehler.
- Parallele Versionen Die Zeilen alte und neue App-Version zeigen, wer in welcher Phase läuft.
- Zu früh verpflichtend In der Phase „Pflicht zu früh“ sind alle drei Zeilen rot.
Die Spalte Rechnungskennung wird optional angelegt.
- alte App-Versionläuft – ignoriert die neue Spalte
- neue App-Versionläuft – kann die Kennung schreiben
- Rollback auf alte Versionläuft – möglich, Schema bleibt kompatibel
Nutzen & Grenzen
Hilft, wenn
- Große Datenbestände profitieren von kontrollierbaren Teilübertragungen mit sichtbarem Fortschritt.
- Kompatible Schemaänderungen halten alte und neue Softwareversionen während kontinuierlicher Releases arbeitsfähig.
Grenzen
- Doppelte Schreibpfade laufen auseinander; verlässliche Nachführung und ein Abgleich vor der Umstellung sind nötig.
- Destruktive Schritte wie das Löschen einer Spalte beenden den Rückweg; vorher alle Verbraucher und Wiederherstellungsoptionen belegen.
- Große Tabellen verlängern jede Befüllung; bei einer geteilten Tabelle (Shared Database) kennt zudem niemand alle Leser.
In der Praxis
- Kompatible Erweiterung entwerfen. Ergänze neue Strukturen so, dass aktive Versionen weiterarbeiten können. Lege fest, wie Werte zunächst geschrieben und gelesen werden. Das Ergebnis ist ein Schema, das den geplanten Parallelbetrieb unterstützt.
- Backfill kontrolliert durchführen. Begrenze Batchgröße und Last, speichere Fortschritt und definiere Wiederaufnahme nach Unterbrechungen. Behandle gleichzeitig geänderte Daten nachvollziehbar. Damit bleiben Fortschritt und Auswirkungen auf den laufenden Betrieb sichtbar.
- Vollständigkeit belegen und Contract planen. Vergleiche Daten fachlich, prüfe Leser und beobachte alte Zugriffe. Bestimme erst danach den Zeitpunkt zur Entfernung des alten Pfads. Das Ergebnis ist ein nachweisbarer Übergang mit klarer Grenze für die Bereinigung.
Ausführliche Erklärung lesen
Eine Datenmigration verändert gespeicherte Werte, ihre Struktur oder ihren Ablageort. Bei fortlaufendem Betrieb können alte und neue Softwareversionen parallel arbeiten. Das Muster Expand-Migrate-Contract ergänzt zuerst die neue Struktur, überträgt den Bestand kontrolliert, stellt Verbraucher um und entfernt danach die alte Form. Es steht in Beziehung zu SQL & NoSQL und kompatiblen Deployment & Rollout.
Backfills benötigen begrenzte Batches, Fortschrittsmarken, Wiederanlauf und eine Regel für gleichzeitige Änderungen. Abgleiche über Zähler, Stichproben und fachliche Bedingungen belegen die Übertragung. Doppelte Schreibpfade können auseinanderlaufen und brauchen eine atomare Kopplung oder verlässliche Nachführung. Der Contract-Schritt erfolgt nach dem Nachweis, dass aktive Leser die alte Form nicht mehr nutzen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was ist in der Phase „Pflicht zu früh“ rot?
Lösung mit Begründung ansehen
Alle drei Zeilen: Die alte Version kann nicht speichern, die neue liest leere Kennungen, ein Rollback ist unmöglich.
AnwendenAuf eine neue Lage übertragen
Ein alter Worker erzeugt noch Bestellungen ohne Rechnungskennung. Darfst du die Spalte schon als Pflicht anlegen?
Lösung mit Begründung ansehen
Nein. Lege sie zuerst optional an, aktualisiere alle Schreibpfade und befülle den Bestand. Verbindlich wird sie erst in Schritt 4.
BewertenEine Alternative abwägen
Das Team überlegt, Spalte, Befüllung und Pflicht in einem einzigen Deployment zu erledigen. Wie bewertest du das?
Lösung mit Begründung ansehen
Ein Deployment ist schneller und hat weniger Zwischenstände. Bei parallel laufenden Versionen riskiert es aber Fehler und lässt keinen sicheren Rückweg, während die Einzelschritte jeweils kompatibel bleiben.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Martin Fowler – Evolutionary Database Design (öffnet in neuem Tab)Beschreibt versionierte Datenbankänderungen und die Zusammenarbeit von Schema und Anwendung.
- Martin Fowler – Parallel Change (öffnet in neuem Tab)Erklärt Expand-and-contract für kompatible Übergänge während einer Migration.
- Prisma – Data migration using expand and contract (öffnet in neuem Tab)Zeigt Schemaerweiterung, Datenüberführung und anschließendes Entfernen alter Strukturen.