Beobachtet man die Entwicklung von Unternehmenssoftware in den letzten zwei Jahrzehnten, so ist ein Trend unverkennbar: die Verlagerung von Datenbanken in die Cloud.
Ich war an einigen Migrationsprojekten beteiligt, deren Ziel es war, bestehende On-Premise-Datenbanken in Cloud-Datenbanken von Amazon Web Services (AWS) zu überführen. Obwohl die AWS-Dokumentation die Einfachheit dieser Aufgabe betont, möchte ich darauf hinweisen, dass die Umsetzung eines solchen Vorhabens nicht immer problemlos verläuft und es zu Komplikationen kommen kann.
Dieser Beitrag beleuchtet praktische Erfahrungen im folgenden Kontext:
- Die Quelle: Obwohl die Art der Quelle theoretisch irrelevant ist (ein ähnlicher Ansatz lässt sich für die meisten gängigen Datenbanksysteme anwenden), war Oracle in großen Unternehmen lange das bevorzugte Datenbanksystem, weshalb ich mich darauf konzentrieren werde.
- Das Ziel: An dieser Stelle ist keine spezifische Datenbank erforderlich. Sie können eine beliebige Zieldatenbank in AWS wählen, und der Ansatz bleibt anwendbar.
- Der Modus: Sie haben die Wahl zwischen einer vollständigen oder inkrementellen Aktualisierung. Hierbei kann es sich um eine Batch-Datenladung (zeitversetzter Status von Quelle und Ziel) oder eine (nahezu) Echtzeit-Datenladung handeln. Beide Varianten werden hier behandelt.
- Die Häufigkeit: Sie können eine einmalige Migration mit anschließender vollständiger Umstellung auf die Cloud durchführen oder eine Übergangszeit benötigen, in der die Daten auf beiden Seiten gleichzeitig aktualisiert werden müssen. Dies erfordert die Entwicklung einer täglichen Synchronisierung zwischen On-Premise und AWS. Ersteres ist einfacher und sinnvoller, aber letzteres wird häufiger verlangt und weist mehr potenzielle Fallstricke auf. Ich werde beide Szenarien erörtern.
Problemstellung
Die Anforderung ist oft simpel:
Wir möchten mit der Entwicklung von Diensten innerhalb von AWS beginnen, daher kopieren Sie bitte alle unsere Daten in die Datenbank „ABC“. Schnell und unkompliziert. Wir benötigen die Daten sofort in AWS. Später werden wir prüfen, welche Änderungen am DB-Design erforderlich sind, um es an unsere Aktivitäten anzupassen.
Bevor Sie fortfahren, sollten Sie Folgendes beachten:
- Überstürzen Sie nicht die Idee, einfach alles zu kopieren und sich später darum zu kümmern. Es mag zwar die einfachste und schnellste Lösung sein, birgt aber das Risiko, ein grundlegendes Architekturproblem zu schaffen, das später nur durch umfangreiches Refactoring der neuen Cloud-Plattform behoben werden kann. Das Cloud-Ökosystem unterscheidet sich grundlegend vom On-Premise-Ökosystem. Mit der Zeit werden neue Dienste eingeführt und unterschiedlich genutzt. Eine 1:1-Replikation des On-Premise-Zustands in der Cloud ist fast nie ratsam. Dies mag in Einzelfällen anders sein, sollte jedoch immer gründlich geprüft werden.
- Hinterfragen Sie die Anforderung kritisch:
- Wer wird der typische Nutzer der neuen Plattform sein? Während es vor Ort ein transaktionaler Geschäftsanwender sein kann, könnte es in der Cloud ein Datenwissenschaftler oder Data-Warehouse-Analyst sein, oder die Daten könnten von einem Dienst (z. B. Databricks, Glue, Modelle für maschinelles Lernen usw.) genutzt werden.
- Werden die regulären täglichen Jobs nach der Umstellung in die Cloud fortgesetzt? Wenn nicht, wie werden sie sich voraussichtlich ändern?
- Erwarten Sie ein erhebliches Datenwachstum im Laufe der Zeit? Die Antwort lautet höchstwahrscheinlich ja, da dies oft der Hauptgrund für eine Migration in die Cloud ist. Dafür sollte ein neues Datenmodell bereitstehen.
- Antizipieren Sie typische Abfragen, die die neue Datenbank von den Nutzern erhalten wird. Dies definiert, wie stark das bestehende Datenmodell verändert werden sollte, um die Leistungsfähigkeit zu gewährleisten.
Einrichtung der Migration
Nachdem die Zieldatenbank ausgewählt und das Datenmodell zufriedenstellend diskutiert wurde, ist der nächste Schritt die Auseinandersetzung mit dem AWS Schema Conversion Tool. Dieses Tool kann in folgenden Bereichen hilfreich sein:
- Analyse und Extraktion des Quelldatenmodells. Das SCT liest die Struktur der aktuellen On-Premise-Datenbank und generiert daraus ein Quelldatenmodell.
- Vorschlagen einer Zieldatenmodellstruktur basierend auf der Zieldatenbank.
- Generierung von Bereitstellungsskripten für die Zieldatenbank, um das Zieldatenmodell zu installieren (basierend auf den Erkenntnissen aus der Quelldatenbank). Dadurch werden Skripte generiert, mit denen die Datenbank in der Cloud für das Laden von Daten aus der lokalen Datenbank vorbereitet wird.
Referenz: AWS-Dokumentation
Nun einige Tipps zur Nutzung des Schema Conversion Tools.
Erstens sollte die Ausgabe des Tools fast nie direkt übernommen werden. Betrachten Sie sie eher als Referenzergebnisse, die Sie an Ihre spezifischen Bedürfnisse und die Nutzung der Daten in der Cloud anpassen sollten.
Zweitens wurden die Tabellen früher wahrscheinlich von Nutzern ausgewählt, die schnelle Ergebnisse zu einer konkreten Datendomänenentität benötigten. Jetzt könnten die Daten jedoch für Analysezwecke abgerufen werden. Datenbankindizes, die in der On-Premise-Datenbank funktionierten, sind jetzt möglicherweise nutzlos und beeinträchtigen die Leistung des DB-Systems im Zusammenhang mit dieser neuen Nutzung sogar. Möglicherweise möchten Sie die Daten im Zielsystem auch anders partitionieren als im Quellsystem.
Es kann auch sinnvoll sein, während des Migrationsprozesses Datentransformationen durchzuführen, was im Grunde bedeutet, dass das Zieldatenmodell für einige Tabellen verändert wird (so dass es keine 1:1-Kopien mehr sind). Die Transformationsregeln müssen dann in das Migrationstool implementiert werden.
Wenn Quell- und Zieldatenbanken vom gleichen Typ sind (z. B. Oracle On-Premise vs. Oracle in AWS, PostgreSQL vs. Aurora Postgresql usw.), empfiehlt es sich, ein dediziertes Migrationstool zu verwenden, das die jeweilige Datenbank nativ unterstützt (z. B. Exporte und Importe von Data Pump, Oracle Goldengate usw.).
In den meisten Fällen sind Quell- und Zieldatenbank jedoch nicht kompatibel, und dann ist der AWS Database Migration Service das offensichtliche Mittel der Wahl.
Referenz: AWS-Dokumentation
AWS DMS ermöglicht die Konfiguration einer Aufgabenliste auf Tabellenebene, die Folgendes definiert:
- Die genaue Quelldatenbank und -tabelle, mit der eine Verbindung hergestellt werden soll.
- Anweisungsspezifikationen, die zum Abrufen der Daten für die Zieltabelle verwendet werden.
- Transformationswerkzeuge (falls vorhanden), die definieren, wie die Quelldaten den Zieldaten zugeordnet werden sollen (falls keine 1:1-Beziehung besteht).
- Die genaue Zieldatenbank und -tabelle, in die die Daten geladen werden sollen.
Die Konfiguration der DMS-Aufgaben erfolgt in einem benutzerfreundlichen Format wie JSON.
Im einfachsten Fall müssen Sie nun nur noch die Bereitstellungsskripte in der Zieldatenbank ausführen und die DMS-Aufgabe starten. Aber das ist nicht alles, was dazu gehört.
Einmalige vollständige Datenmigration
Der einfachste Fall ist, wenn die gesamte Datenbank einmalig in die Cloud-Zieldatenbank verschoben werden soll. Dann ist Folgendes zu tun:
- Definieren Sie eine DMS-Aufgabe für jede Quelltabelle.
- Stellen Sie sicher, dass die Konfiguration der DMS-Jobs korrekt ist. Dies umfasst die Einrichtung einer angemessenen Parallelität, das Caching von Variablen, die Konfiguration des DMS-Servers, die Dimensionierung des DMS-Clusters usw. Dies ist in der Regel die zeitaufwendigste Phase, da sie umfangreiche Tests und die Feinabstimmung des optimalen Konfigurationszustands erfordert.
- Vergewissern Sie sich, dass jede Zieltabelle in der Zieldatenbank mit der erwarteten Tabellenstruktur (leer) erstellt wurde.
- Planen Sie ein Zeitfenster für die Datenmigration ein. Stellen Sie vorher sicher (durch Leistungstests), dass das Zeitfenster ausreicht, um die Migration abzuschließen. Während der Migration selbst kann die Quelldatenbank aus Performance-Sicht eingeschränkt werden. Außerdem sollte sich die Quelldatenbank während der Migration nicht ändern, da die migrierten Daten sonst von denen in der Quelldatenbank nach Abschluss der Migration abweichen könnten.
Wenn die Konfiguration von DMS gut gemacht ist, wird in diesem Szenario nichts Gravierendes passieren. Jede einzelne Quelltabelle wird erfasst und in die AWS-Zieldatenbank kopiert. Die einzigen Bedenken sind die Leistung der Aktivität und die Sicherstellung, dass die Dimensionierung in jedem Schritt korrekt ist, damit sie nicht wegen unzureichendem Speicherplatz fehlschlägt.
Inkrementelle tägliche Synchronisation
Hier wird es kompliziert. In einer idealen Welt würde alles reibungslos funktionieren. Aber die Welt ist nie ideal.
DMS kann in zwei Modi betrieben werden:
- Volllast – Standardmodus, wie oben beschrieben. DMS-Aufgaben werden gestartet, wenn Sie sie starten oder wenn ihr Start geplant ist. Nach Abschluss sind die DMS-Aufgaben beendet.
- Change Data Capture (CDC) – In diesem Modus wird die DMS-Aufgabe kontinuierlich ausgeführt. DMS überwacht die Quelldatenbank auf Änderungen auf Tabellenebene. Wenn eine Änderung auftritt, wird sofort versucht, die Änderung in der Zieldatenbank basierend auf der Konfiguration innerhalb der DMS-Aufgabe zu replizieren.
Wenn Sie sich für CDC entscheiden, müssen Sie eine weitere Entscheidung treffen – nämlich, wie CDC die Delta-Änderungen aus der Quelldatenbank extrahiert.
#1. Oracle Redo Logs Reader
Eine Option ist die Verwendung eines nativen Datenbank-Redo-Logs-Readers von Oracle, den CDC verwenden kann, um die geänderten Daten abzurufen und die entsprechenden Änderungen in der Zieldatenbank zu replizieren.
Obwohl dies bei Oracle als Quelle eine naheliegende Wahl zu sein scheint, gibt es einen Haken: Der Oracle Redo-Logs-Reader greift auf den Quell-Oracle-Cluster zu und beeinflusst somit alle anderen Aktivitäten in der Datenbank (er erstellt aktive Sitzungen in der Datenbank).
Je mehr DMS-Aufgaben Sie konfiguriert haben (oder je mehr DMS-Cluster parallel), desto stärker müssen Sie den Oracle-Cluster wahrscheinlich vergrößern – im Grunde müssen Sie die vertikale Skalierung Ihres primären Oracle-Datenbank-Clusters anpassen. Dies wirkt sich sicherlich auf die Gesamtkosten der Lösung aus, insbesondere wenn die tägliche Synchronisation über einen längeren Zeitraum im Projekt verbleibt.
#2. AWS DMS Log Miner
Im Gegensatz zur obigen Option ist dies eine native AWS-Lösung für dasselbe Problem. In diesem Fall wirkt sich DMS nicht auf die Oracle-Quelldatenbank aus. Stattdessen kopiert es die Redo-Protokolle von Oracle in den DMS-Cluster und führt dort die gesamte Verarbeitung durch. Obwohl dies Oracle-Ressourcen spart, ist es die langsamere Lösung, da mehr Vorgänge erforderlich sind. Der benutzerdefinierte Reader für Oracle-Redo-Logs arbeitet wahrscheinlich langsamer als der native Reader von Oracle.
Abhängig von der Größe der Quelldatenbank und der Anzahl der täglichen Änderungen erhalten Sie im besten Fall eine nahezu Echtzeit-Synchronisation der Daten aus der On-Premise-Oracle-Datenbank in die AWS-Cloud-Datenbank.
In anderen Szenarien ist die Synchronisierung nicht annähernd in Echtzeit, aber Sie können versuchen, der akzeptierten Verzögerung (zwischen Quelle und Ziel) so nahe wie möglich zu kommen, indem Sie die Leistungskonfiguration und Parallelität der Quell- und Zielcluster optimieren oder mit der Anzahl der DMS-Aufgaben und deren Verteilung auf die CDC-Instanzen experimentieren.
Beachten Sie auch, welche Änderungen an Quelltabellen von CDC unterstützt werden (z. B. das Hinzufügen einer Spalte), da nicht alle möglichen Änderungen unterstützt werden. In einigen Fällen besteht die einzige Möglichkeit darin, die Zieltabelle manuell zu ändern und die CDC-Aufgabe von Grund auf neu zu starten (wobei alle vorhandenen Daten in der Zieldatenbank verloren gehen).
Wenn die Dinge schief gehen, egal was passiert
Ich habe die Erfahrung gemacht, dass es ein spezielles Szenario im Zusammenhang mit DMS gibt, in dem das Versprechen einer täglichen Replikation schwer zu erfüllen ist.
Das DMS kann die Redo-Logs nur mit einer definierten Geschwindigkeit verarbeiten. Es spielt keine Rolle, ob mehrere DMS-Instanzen Ihre Aufgaben ausführen. Jede DMS-Instanz liest die Redo-Logs nur mit einer einzigen definierten Geschwindigkeit, und jede muss sie vollständig lesen. Es spielt keine Rolle, ob Sie Oracle Redo Logs oder AWS Log Miner verwenden. Beide haben diese Einschränkung.
Wenn die Quelldatenbank innerhalb eines Tages eine große Anzahl von Änderungen enthält, bei denen die Oracle Redo-Protokolle täglich enorm wachsen (z. B. 500 GB+), wird CDC einfach nicht funktionieren. Die Replikation wird nicht bis zum Ende des Tages abgeschlossen sein. Es wird eine unverarbeitete Menge an Arbeit zum nächsten Tag mitbringen, wo bereits neue Änderungen zur Replikation anstehen. Die Menge an unverarbeiteten Daten wächst von Tag zu Tag.
In diesem speziellen Fall war CDC keine Option (nach vielen Leistungstests und Versuchen). Die einzige Möglichkeit, sicherzustellen, dass zumindest alle Delta-Änderungen des aktuellen Tages am selben Tag repliziert werden, bestand darin, wie folgt vorzugehen:
- Trennen Sie wirklich große Tabellen, die nicht so oft verwendet werden, und replizieren Sie sie nur einmal pro Woche (z. B. am Wochenende).
- Konfigurieren Sie die Replikation von nicht so großen, aber immer noch großen Tabellen, um sie auf mehrere DMS-Aufgaben aufzuteilen. Eine Tabelle wurde schließlich von 10 oder mehr separaten DMS-Aufgaben parallel migriert, um sicherzustellen, dass die Datenaufteilung zwischen den DMS-Aufgaben eindeutig ist (hier ist benutzerdefinierte Codierung erforderlich), und führen Sie diese täglich aus.
- Fügen Sie weitere (in diesem Fall bis zu 4) DMS-Instanzen hinzu und verteilen Sie die DMS-Aufgaben gleichmäßig, d. h. nicht nur nach der Anzahl der Tabellen, sondern auch nach ihrer Größe.
Im Grunde haben wir den Volllastmodus von DMS verwendet, um tägliche Daten zu replizieren, da dies die einzige Möglichkeit war, eine Datenreplikation mindestens am selben Tag abzuschließen.
Keine perfekte Lösung, aber sie funktioniert auch nach vielen Jahren noch auf die gleiche Weise. Vielleicht ist sie also gar nicht so schlecht. 😃