Daten · Datenbankmigration
Datenbankmigration für geschäftskritische Systeme
Ihre Datenbank wechselt Engine, Version oder Umgebung, und das Geschäft läuft weiter. Wir messen vorab, wie lange die Umstellung dauert, wählen danach das Verfahren und legen den Rückfallweg fest, bevor umgeschaltet wird.
- Von Oracle, SQL Server, MySQL nach PostgreSQL
- Testmigration mit gemessener Dauer
- Rückfallkriterien vor dem Cutover
01Ausgangslage
Wenn die Datenbank nicht ausfallen darf, aber wechseln muss
SKAFFON plant und führt Datenbankmigrationen durch: von Oracle, SQL Server oder MySQL nach PostgreSQL sowie zwischen Plattformen, Versionen und Hosting-Umgebungen.
Für IT-Leitung und Anwendungsverantwortliche, die eine Datenbank wechseln, aktualisieren oder verlagern müssen: Weiter unten finden Sie die Entscheidung zwischen Dump-basierter Migration und laufender Replikation (CDC), und für jede Umschaltung legen wir einen Rückfallweg fest.
02Auslöser
Fünf Gründe, warum Datenbanken umziehen
-
Lizenz und Supportende
Lizenzkosten oder das Supportende einer Datenbankversion zwingen zur Entscheidung.
-
Wechsel zu PostgreSQL
Der Schritt zu Open Source, meist mit Engine-Wechsel und Schemakonvertierung.
-
Neue Umgebung
Umzug in eine andere Umgebung, etwa die souveräne Cloud oder eigene Infrastruktur.
-
Major-Upgrade
Upgrade einer bestehenden Datenbank auf eine neue Hauptversion.
-
Zusammenführung
Mehrere Datenbanken werden in einer zusammengeführt.
03Ablauf
Sechs Schritte von der Bestandsaufnahme bis zur Umschaltung
Jede Migration durchläuft diese Folge. Die Testmigration in Schritt 3 entscheidet über das Verfahren.
- 01
Inventar
Ergebnis: RisikoberichtDatenbanken, Schemata, Objekte (Tabellen, Indizes, Sichten, Trigger, Prozeduren, Sequenzen), Datenmenge, Wachstum, Abhängigkeiten, Clients, Jobs und Schnittstellen. Besonderheiten wie Large Objects, proprietäre Datentypen oder Erweiterungen werden hier sichtbar.
- 02
Schemakonvertierung
Nur bei Engine-WechselAbbildung von Typen und Objekten, manuelle Überarbeitung nicht automatisch konvertierbarer Logik, Anpassung der Anwendung. Bei Versions- oder Hosting-Wechsel derselben Engine entfällt das weitgehend.
- 03
Testmigration
Ergebnis: gemessene DauerVollständige Übernahme in eine Testumgebung, mit gemessener Dauer. Daraus folgt, ob das Ausfallfenster ausreicht oder ein anderes Verfahren nötig ist.
- 04
Validierung
Ergebnis: AbnahmeprotokollZeilenzahlen, Prüfsummen über Tabellen oder Stichproben, fachliche Abfragen, Vergleich von Ergebnissen zwischen Quelle und Ziel, Performance-Vergleich mit realistischen Abfragen und Prüfung von Sequenzen und Berechtigungen.
- 05
Cutover
UmschaltungAnwendung stoppen oder in den Lesemodus versetzen, letzte Änderungen übernehmen, Validierung, Verbindungsumstellung, Anwendungstest.
- 06
Rückfall
Vor dem Cutover festgelegtBis zu welchem Zeitpunkt und mit welchen Daten ist ein Zurück möglich? Nach produktivem Schreiben auf dem Ziel setzt ein Rückweg voraus, dass Änderungen zurückgeführt werden, etwa durch Rückwärts-Replikation. Das ist aufwendig und wird nur dort geplant, wo es erforderlich ist.
04Verfahren
So unterscheiden sich die beiden Wege zeitlich
Dump und Restore halten die Anwendung während des gesamten Kopiervorgangs an, CDC verlagert das Kopieren in den laufenden Betrieb.
05Entscheidungshilfe
Dump oder CDC: Das Ausfallfenster entscheidet
Der Kern der Verfahrenswahl ist das zulässige Ausfallfenster im Verhältnis zur Datenmenge.
| Kriterium | Dump und Restore | CDC (laufende Replikation) |
|---|---|---|
| Prinzip | Konsistenter Export, Import im Ziel | Initiale Kopie, danach laufende Übernahme von Änderungen bis zur Umschaltung |
| Ausfallfenster | Mindestens so lang wie Export plus Import plus Validierung, sofern währenddessen nicht geschrieben werden darf | Kurz: Umschaltung nach Synchronisation |
| Komplexität | Gering | Höher: zusätzliche Werkzeuge, Überwachung der Verzögerung, Umgang mit Schemaänderungen |
| Geeignet für | Kleine bis mittlere Datenmengen, Wartungsfenster vorhanden, Versions- oder Hostingwechsel | Große Datenbanken, enge Ausfallfenster |
| Engine-Wechsel | Möglich, wenn Schema vorher konvertiert wurde | Möglich mit passenden Werkzeugen; Typ-Abbildung bleibt nötig |
| Typische Fallstricke | Dauer unterschätzt | Nicht replizierte Objekte, Sequenzen, Konflikte |
Faustregel
Ohne Testmigration entscheiden wir nicht
Passt die gemessene Dauer aus der Testmigration in das Fenster, nehmen wir Dump und Restore: weniger Teile, weniger Fehlerquellen. Reicht das Fenster nicht, wechseln wir zu CDC und planen den Mehraufwand ein. Schätzungen am Schreibtisch ersetzen die Messung nicht.
06PostgreSQL-Dump
pg_dump: konsistent im laufenden Betrieb, aber mit Snapshot-Grenze
pg_dump erzeugt laut Dokumentation konsistente Exporte, auch während die Datenbank genutzt wird, und blockiert weder lesende noch schreibende Nutzer. Für das Zeitfenster zählt trotzdem: Änderungen nach dem Snapshot gehen nicht mit, es sei denn, die Anwendung ruht.
- Parallel arbeitet pg_dump nur im Verzeichnisformat (
-Fd -j). - Die Ausgabe lässt sich in neuere PostgreSQL-Versionen laden.
- pg_dump dumpt keine Server, die neuer sind als es selbst.
07Logische Replikation
Was die PostgreSQL-Replikation nicht mitnimmt
Die logische Replikation hat dokumentierte Grenzen (Restrictions). Daraus ergibt sich, was bei CDC vor der Umschaltung zu erledigen ist.
- Schema und DDL werden nicht repliziert: Schema vorab kopieren.
- Sequenzdaten werden nicht repliziert: Sequenzen vor der Umschaltung nachziehen.
- Large Objects werden nicht repliziert: anders behandeln.
- Nur Tabellen werden unterstützt, keine Sichten.
- Tabellen ohne Primärschlüssel oder Replica Identity prüfen.
- Bei Engine-Wechsel kommen Werkzeuge hinzu, die Änderungen aus Oracle, SQL Server oder MySQL lesen. Die Auswahl hängt von der Quelle ab und wird im Projekt festgelegt.
08Mitwirkung
Fünf Dinge, ohne die wir nicht starten
Ohne diese Punkte lässt sich kein belastbares Migrationskonzept erstellen.
- Lesezugriff auf die Quelldatenbank.
- Lesezugriff auf den Anwendungscode, soweit er Datenbankbesonderheiten nutzt.
- Kenntnis des zulässigen Ausfallfensters.
- Ein Ansprechpartner der Fachseite für die Abnahme.
- Die Klärung, ob die Anwendung angepasst werden darf.
09Ergebnisse
Was Sie am Projektende in der Hand haben
-
Inventar- und Risikobericht
Die Bestandsaufnahme aller Objekte, Abhängigkeiten und Besonderheiten.
-
Zielarchitektur und Migrationskonzept
Inklusive gewähltem Verfahren und Begründung.
-
Konvertierte Schemata und Skripte
Migrationsskripte liegen versioniert vor.
-
Validierung und Abnahme
Validierungsabfragen und Abnahmeprotokoll.
-
Cutover-Plan mit Rückfallkriterien
Festgelegt, bevor umgeschaltet wird.
-
Dokumentation und Betrieb
Dokumentation der umgesetzten Migration; auf Wunsch Betrieb der Zieldatenbank (Managed PostgreSQL).
10Sicherheit im Projekt
Produktivdaten unterwegs: Zugänge, Verschlüsselung, Testdaten
Datenübertragung erfolgt verschlüsselt, Zugänge sind personalisiert und werden nach Projektende entzogen. Wo Produktivdaten personenbezogen sind, klären wir vorab mit Ihnen, ob Tests mit maskierten Daten laufen.
Rechtliche Bewertung und Auftragsverarbeitung gehören zu Ihrem Datenschutzverantwortlichen; wir unterstützen technisch.
11Abgrenzung
Wo wir Migrationen übernehmen und wo nicht
Passt
- Geschäftskritische Datenbanken, bei denen ein langer Stillstand das Geschäft trifft.
- Projekte mit Test- und Abnahmephase.
Passt nicht
- Reiner Datei- oder Gerätetransfer ohne Datenbank.
- Erwartung eines automatischen Konvertierungswerkzeugs als vollständige Lösung: Logik in Prozeduren und Triggern bleibt Ingenieursarbeit.
- Migration ohne Test- und Abnahmephase.
12Weiterlesen
Was vor und nach der Migration anfällt
-
Daten
Alle Datenthemen im Überblick.
-
DevOps-Beratung
Automatisierung der Umsetzung.
Quelle, Ziel, Datenmenge und Ausfallfenster beschreiben
Schicken Sie uns diese vier Angaben in einer Projektanfrage, dann können wir das Verfahren einordnen.