Datenbankmigration: Konzepte und Prinzipien (Teil 2)

Last reviewed 2024-03-11 UTC

In diesem Dokument wird das Einrichten und Ausführen des Datenbankmigrationsprozesses einschließlich Fehlerszenarien erläutert. Dieses Dokument ist Teil 2 von zwei Teilen. In Teil 1 werden die Konzepte, Prinzipien und Terminologie der Datenbankmigration, die praktisch ohne Ausfallzeiten erfolgt, für Cloud-Architekten erläutert, die Datenbanken von lokalen oder anderen Cloud-Umgebungen zu Google Cloud migrieren müssen.

Einrichtung der Datenbankmigration

In diesem Abschnitt werden die verschiedenen Phasen einer Datenbankmigration beschrieben. Zuerst richten Sie die Migration ein. Nachdem Sie die Migration abgeschlossen und Clients auf die Zieldatenbanken umgestellt haben, entfernen Sie entweder die Quelldatenbanken oder implementieren bei Bedarf einen Fallback-Plan, wenn nach dem Wechsel Probleme bei der Migration auftreten. Ein Fallback sorgt für Geschäftskontinuität.

Während der Migration müssen Sie besonders auf Schema- oder Datenänderungen achten, die möglicherweise eingeführt werden. Weitere Informationen zu den Auswirkungen dieser Änderungen finden Sie weiter unten in diesem Dokument unter Dynamische Änderungen während der Migration.

Zielschemaspezifikation

Für jedes Zieldatenbanksystem müssen Sie sein Schema definieren und erstellen. Bei einer homogenen Datenbankmigration können Sie diese Spezifikation schneller erstellen, indem Sie das Quelldatenbankschema in die Zieldatenbank exportieren und so das Zieldatenbankschema erstellen.

Es ist wichtig, wie Sie Ihr Schema benennen. Eine Möglichkeit besteht darin, den Namen des Quell- und Zielschemas abzugleichen. Obwohl dies den Wechsel zwischen Clients vereinfacht, könnte dieser Ansatz Nutzer verwirren, wenn Tools gleichzeitig eine Verbindung zum Quell- und zum Zieldatenbankschema herstellen, um beispielsweise Daten zu vergleichen. Wenn Sie den Schemanamen mithilfe einer Konfigurationsdatei abstrahieren, können Sie die Schemas leichter unterscheiden, wenn Sie den Zieldatenbankschemas andere Namen als in der Quelle geben.

Bei heterogenen Datenbankmigrationen müssen Sie jedes Zieldatenbankschema erstellen. Dieser Entwicklungsprozess kann mehrere Iterationen umfassen. Bevor Sie die Migration implementieren können, müssen Sie die Schemas möglicherweise noch ändern, um den Migrationsprozess und alle Datenänderungen zu berücksichtigen.

Da Sie Zieldatenbanken wahrscheinlich mehrmals erstellen, wenn Sie Ihre Migration testen und ausführen, muss das Erstellen des Schemas wiederholbar sein (idealerweise über Installationsskripts). Mit einem Code-Management-System können Sie die Version von Skripts steuern, für Konsistenz sorgen und auf den Änderungsverlauf der Skripts zugreifen.

Abfragemigration und Ausführungssemantik

Schließlich müssen Sie Clients so umstellen, dass sie nicht mehr auf die Quelldatenbanksysteme zugreifen, sondern auf die Zieldatenbanksysteme. Bei homogenen Datenbankintegrationen können die Abfragen unverändert bleiben, wenn die Schemas nicht geändert werden. Die Clients müssen zwar in den Zieldatenbanksystemen getestet werden, sie müssen aufgrund von Abfragen aber nicht geändert werden.

Bei heterogenen Datenbankmigrationen im Allgemeinen müssen Sie die Abfragen ändern, da sich die Schemas zwischen der Quell- und der Zieldatenbank unterscheiden. Der Unterschied kann darin bestehen, dass der Datentyp zwischen Quell- und Zieldatenbank nicht übereinstimmt. Darüber hinaus stehen vielleicht nicht alle Funktionen der in den Quelldatenbanksystemen verfügbaren Abfragesprache in den Zieldatenbanksystemen zur Verfügung oder umgekehrt. In extremen Fällen müssen Sie möglicherweise eine Abfrage von einem Quelldatenbanksystem in mehrere Abfragen im Zielsystem umwandeln. In einem umgekehrten Szenario, in dem in der Zieldatenbank mehr Funktionen für die Abfragesprache verfügbar sind als in der Quelle, müssen Sie möglicherweise mehrere Abfragen aus der Quelldatenbank zu einer einzigen Abfrage in der entsprechenden Zieldatenbank kombinieren.

Auch die Semantik von Abfragen kann abweichen. Einige Datenbanksysteme nehmen beispielsweise eine Aktualisierung innerhalb einer Transaktion unmittelbar mit dieser Transaktion vor. Wenn also dasselbe Datenelement gelesen wird, wird der aktualisierte Wert abgerufen. Andere Systeme führen eine Aktualisierung nicht sofort durch und warten, bis der Commit der Transaktion durchgeführt wird. Wenn die Logik im Quelldatenbanksystem auf der Erfassung des Schreibvorgangs beruht, kann dieselbe Logik in der Zieldatenbank falsche Daten oder sogar Fehler verursachen.

Wenn Sie Abfragen migrieren müssen, müssen Sie alle Funktionen testen, um dafür zu sorgen, dass das Verhalten der Clients vor und nach der Migration gleich ist. Sie können Tests auch auf Datenebene durchführen. Diese Tests ersetzen jedoch keine Tests auf Clientebene. Clients führen Abfragen aus Sicht der Geschäftslogik aus und können nur auf Geschäftslogikebene getestet werden.

Migrationsprozesse

Bei heterogenen Datenbankmigrationen geben Migrationsprozesse an, wie aus Quelldatenbanksystemen extrahierte Daten geändert und in Zieldatenbanken eingefügt werden. Datenänderungen, wie sie unter Datenänderungen in diesem Dokument erläutert werden, werden definiert und ausgeführt, während Datenelemente aus den Quelldatenbanken extrahiert und an die Zieldatenbanken übertragen werden.

Bei homogenen Datenbankmigrationen ist keine Datenänderung erforderlich, wenn die Schemas der Quell- und Zieldatenbanken gleich sind. Daten werden so in Zieldatenbanken eingefügt, wie sie aus Quelldatenbanken extrahiert wurden.

Je nach Datenbankmigrationssystem sind möglicherweise mehrere Konfigurationen erforderlich. Sie müssen beispielsweise angeben, ob Daten, die geändert und übertragen werden, zeitweise im Datenbankmigrationssystem gespeichert werden müssen. Das Speichern der Daten kann den gesamten Migrationsprozess verlangsamen, die Wiederherstellung jedoch im Falle eines Fehlers erheblich beschleunigen. Möglicherweise müssen Sie den Bestätigungstyp angeben. Einige Datenbankmigrationssysteme fragen beispielsweise Quell- und Zielsysteme ab, um die Äquivalenz des bis zur Abfrage migrierten Datasets zu ermitteln. Für die Fehlerbehandlung ist es erforderlich, dass Sie das Verhalten bei der Fehlerbehebung angeben. Auch hier hängt diese Anforderung vom verwendeten Datenbankmigrationssystem ab.

Natürlich müssen Sie Ihre Datenmigration gründlich und immer wieder testen. Im Idealfall wird Ihre Migration darauf getestet, ob Folgendes gewährleistet ist: dass jedes bekannte Datenelement migriert wird, keine Datenänderungsfehler auftreten, die Leistung und der Durchsatz ausreichen und die Zeit bis zur Migration erreicht werden kann.

Fallback-Prozesse

Während einer Datenbankmigration bleiben die Quelldatenbanken in Betrieb, es sei denn, die Migration beinhaltet geplante Ausfallzeiten. Wenn die Datenbankmigration zu einem beliebigen Zeitpunkt fehlschlägt, können Sie die Migration im schlimmsten Fall abbrechen und die Zieldatenbank auf ihren Ausgangszustand zurücksetzen. Nachdem Sie die Fehler behoben haben, können Sie die Datenbankmigration neu starten. Der Fehler und die Lösung haben keinen Einfluss auf die ausgeführten Quelldatenbanksysteme.

Wenn nach Abschluss der Datenbankmigration Fehler auftreten und Clients auf die Zieldatenbanken umgestellt werden, kann sich der Fehler- und Lösungsprozess auf die Clients auswirken, sodass sie nicht ordnungsgemäß funktionieren. Im besten Fall wird der Fehler schnell behoben und die Ausfallzeiten für Clients sind kurz. Im schlimmsten Fall wird der Fehler nicht behoben oder die Lösung dauert lange und Sie müssen die Clients wieder auf die Quelldatenbanken umstellen.

Damit Clients wieder auf die Quelldatenbanken umgestellt werden können, müssen Sie alle Datenänderungen in den Zieldatenbanken zurück in die Quelldatenbanken migrieren. Sie können diesen Prozess als separate, vollständige Datenbankmigration einrichten und ausführen. Da Clients zu diesem Zeitpunkt jedoch nicht in den Zieldatenbanken ausgeführt werden, kommt es zu erheblichen Ausfallzeiten.

Zur Vermeidung von Ausfallzeiten des Clients in diesem Szenario müssen Sie Ihre Migrationsprozesse direkt nach Abschluss der ursprünglichen Datenbankmigration starten. Jede Änderung an den Zieldatenbanksystemen wird sofort auf die Quelldatenbanksysteme angewendet. Mit diesem Ansatz wird gewährleistet, dass sowohl das Ziel- als auch Quelldatenbanksysteme immer synchron sind.

Die Vorbereitung eines Fallbacks von Ziel- auf Quelldatenbanken erfordert einen erheblichen Aufwand. Es ist wichtig, zu entscheiden, ob Fallback-Prozesse implementiert und getestet werden. Wenn Sie sich dagegen entscheiden, müssen Sie sich der Folgen (erhebliche Ausfallzeiten) bewusst sein.

Ausführung der Datenbankmigration

Die Ausführung einer Datenbankmigration umfasst fünf verschiedene Phasen, die in diesem Abschnitt beschrieben werden. Eine sechste Phase ist ein Fallback. Ein Fallback ist jedoch ein extremer Fall und gilt als Ausnahme von einer normalen Ausführung einer Datenbankmigration.

Der in diesem Abschnitt beschriebene Prozess ist eine heterogene Datenbankmigration praktisch ohne Ausfallzeiten. Wenn erhebliche Ausfallzeiten vorkommen dürfen, können Sie die ersten drei Phasen (anfänglicher Ladevorgang, fortlaufende Migration und Ausgleich) mithilfe des Ansatzes zur Sicherung/Wiederherstellung bzw. zum Export/Import in einer Phase kombinieren.

Eine homogene Datenbankmigration stellt einen Sonderfall dar. Bei dieser Art der Migration können Sie die Replikationsfunktion des Datenbankverwaltungssystems (für die Systeme, die dies unterstützen) verwenden. Bei dieser Funktion werden die Daten migriert, während die Quelldatenbanksysteme weiter ausgeführt werden.

Die hier dargestellten Phasen beschreiben einen Ansatz, den Sie möglicherweise entsprechend den Anforderungen Ihres Datenbankmigrationsprozesses ändern müssen.

Phase 1: Anfänglicher Ladevorgang

Der Ausgangspunkt besteht darin, alle aus allen Quelldatenbanken zu migrierenden Daten zu migrieren. Zu Beginn der Datenmigration haben die Quelldatenbanken einen bestimmten Status, der sich während der Migration ändert.

Ein Tipp zum Starten einer Migration bei gleichzeitiger Durchführung von Änderungen besteht darin, die Datenbanksystemzeit zu notieren, bevor das erste Datenelement extrahiert wird. Mit diesem Zeitstempel können Sie alle Datenbankänderungen ab diesem Zeitpunkt aus dem Transaktionslog ableiten. Außerdem muss im anfänglichen Ladevorgang ein konsistenter Datenbankstatus für alle Daten gelesen werden. Möglicherweise muss die Datenbank kurz gesperrt werden, um das Lesen eines inkonsistenten Datasets zu verhindern.

Diese Phase umfasst Folgendes:

  • Notieren der Datenbanksystemzeit, bevor die Datenbankmigration beginnt.
  • Ausführen eines anfänglichen Lademigrationsprozesses, bei dem das Dataset (vollständig oder teilweise) aus den zu migrierenden Quelldatenbanken abgefragt wird, und Migrieren des Datasets. In einem relationalen Datenbankmodell führen die anfänglichen Lademigrationsprozesse Abfragen wie SELECT * oder Abfragen mit Auswahl oder Projektion oder beides aus. Der Migrationsprozess führt die Datenänderung wie im Prozess angegeben durch.

Während die anfänglichen Lademigrationsprozesse ausgeführt werden, nehmen Clients in der Regel Änderungen an den Quelldatenbanken vor. Da Sie die Datenbanksystemzeit zu Beginn erfassen, können Sie diese Änderungen später aus dem Transaktionslog ableiten.

Das Ergebnis der Phase mit dem anfänglichen Ladevorgang ist die vollständige Migration des anfänglichen Datasets aus den Quelldatenbanksystemen in die Zieldatenbanksysteme. Die Quell- und Zieldatenbanken sind jedoch noch nicht synchronisiert, da Clients die Quelldatenbanken während der Migration wahrscheinlich geändert haben. In Phase 2 werden diese Änderungen erfasst und migriert.

Phase 2: Fortlaufende Migration

Die fortlaufende Migration hat zwei Ziele. Zum einen werden die Änderungen gelesen, die in den Quelldatenbanken nach dem Start des anfänglichen Ladevorgangs vorgenommen wurden. Zum anderen werden diese Änderungen erfasst und in die Zieldatenbanken übertragen.

Diese Phase umfasst Folgendes:

  • Starten der fortlaufenden Migrationsprozesse aus der in Phase 1 erfassten Datenbanksystemzeit. Die Migration liest das Transaktionslog aus dieser Zeit und wendet jede Änderung auf das Zieldatenbanksystem an.
  • Ausführen aller Datenänderungen. Der Migrationsprozess führt diesen Schritt nach Ihren Vorgaben aus.

Änderungen, die nach der Datenbanksystemzeit protokolliert werden, werden manchmal beim anfänglichen Ladevorgang übertragen. Daher ist es möglich, dass diese Änderungen während der fortlaufenden Migration ein zweites Mal angewendet werden. Sie müssen Ihre Migrationsprozesse so definieren, dass Änderungen nicht doppelt angewendet werden, z. B. mithilfe von Kennungen. Angenommen, ein geändertes Datenelement wird beim anfänglichen Ladevorgang übertragen und diese Einfügung wird im Transaktionslog protokolliert. Da das Datenelement eine Kennung hat, kann das Migrationssystem anhand des Transaktionslogs feststellen, dass keine weitere Einfügung erforderlich ist, weil das Datenelement bereits vorhanden ist.

Das Ergebnis der fortlaufenden Migrationsphase ist, dass die Zieldatenbanken entweder vollständig oder fast vollständig mit den Quelldatenbanken synchronisiert werden. Wenn eine Änderung in einem Quelldatenbanksystem nicht migriert wird, haben Sie eine fast synchronisierte Datenbank.

Je nach Konfiguration des Datenbankmigrationssystems können die Diskrepanzen klein oder groß sein. Zur Erhöhung der Effizienz sollte z. B. nicht jede Änderung sofort migriert werden. Andernfalls kann dies zu einer starken Belastung der Quelle führen, wenn es zu einem sprunghaften Anstieg der Änderungen in der Quelle kommt. Im Allgemeinen werden Änderungen in Batches als Bulk-Vorgänge erfasst und migriert. Bei kleineren Batches treten weniger Diskrepanzen zwischen der Quelle und dem Ziel auf. Ihre Quelle kann jedoch höher belastet werden, wenn häufig Änderungen vorgenommen werden.

Wenn die Batchgröße dynamisch konfiguriert wird, ist es am besten, größere Batches anfänglich in der fortlaufenden Migrationsphase zu synchronisieren und dann Batches mit einer schrittweise reduzierten Größe zu synchronisieren, wenn die Datenbanken fast voll sind. Dieser Ansatz macht den Abgleichprozess effizienter und verringert später die Diskrepanz zwischen der Quell- und der Zieldatenbank.

Phase 3: Ausgleich

Um die Umstellung der Clients von der Quell- auf die Zieldatenbank vorzubereiten, müssen Sie sicherstellen, dass die Quelldatenbanken und die Zieldatenbank vollständig synchronisiert sind. Beim Ausgleich werden die verbleibenden Änderungen von den Quell- in die Zieldatenbanken migriert.

Diese Phase umfasst Folgendes:

  • Stilllegen der Quelldatenbanksysteme. Dies bedeutet, dass in der Quelldatenbank keine Datenänderungen vorgenommen werden können und das Transaktionslog keine zusätzlichen Änderungseinträge erhält.
  • Warten auf die Migration aller Änderungen in die Zieldatenbank. Dieser Prozess ist der eigentliche Ausgleich der Änderungen.
  • Sichern der Zieldatenbanken nach Abschluss des Ausgleichs, um einen definierten Ausgangspunkt für zukünftige inkrementelle Sicherungen zu haben.

Das Ergebnis der Ausgleichsphase ist, dass die Quell- und Zieldatenbanksysteme synchronisiert werden und keine Datenänderungen erfolgen.

Damit gewährleistet ist, dass der Ausgleich abgeschlossen ist, kann ein Datenelement für die letzte Einfügung in eine Quelldatenbank geschrieben werden. Sobald dieses Datenelement für die letzte Einfügung in der entsprechenden Zieldatenbank angezeigt wird, ist die Ausgleichsphase abgeschlossen.

Phase 4: Umstellung

Nach Abschluss der Ausgleichsphase können Sie die Clients von den Quell- auf die Zieldatenbanken umstellen. Wir empfehlen folgende Best Practices:

  • Bevor Sie den Zugriff auf die Produktionsdatenbank aktivieren, testen Sie die grundlegenden Funktionen, um zu gewährleisten, dass die Clients einsatzbereit sind und sich wie vorgesehen verhalten. Die Anzahl der Testfälle bestimmt die tatsächliche Ausfallzeit für Ihre Produktionsdatenbank.
  • Sichern Sie die Zieldatenbanken, bevor Sie den Clientzugriff aktivieren. Mit dieser Best Practice wird sichergestellt, dass der anfängliche Status der Zieldatenbank wiederhergestellt werden kann.

Am Ende der Umstellung sind die Clients voll einsatzbereit und beginnen mit dem Zugriff auf Produktionsdatenbanken (in diesem Dokument bisher als Zieldatenbanken bezeichnet).

Phase 5: Löschen der Quelldatenbank

Nach der Umstellung auf Produktionsdatenbanken können Sie die Quelldatenbanken löschen. Es empfiehlt sich, eine abschließende Sicherung jeder Quelldatenbank zu erstellen, damit Sie einen definierten Endstatus haben, auf den zugegriffen werden kann. Datenschutzvorschriften können aus Compliance-Gründen auch abschließende Sicherungen erfordern.

Phase 6: Fallback

Die Implementierung eines Fallbacks kann insbesondere für sehr kritische Datenbankclients ein guter Schutz vor Problemen bei der Migration sein. Ein Fallback ist wie eine Migration, nur in umgekehrter Richtung. Mit einem Fallback richten Sie also eine Migration von den Zieldatenbanken zurück zu den Quelldatenbanken ein. Bei heterogenen Datenbankmigrationen ist der Fallback komplexer. Wir empfehlen daher, die Umstellung erst durchzuführen, nachdem Sie gründlich getestet haben, ob Ihr Datenbankmigrationsprozess und Ihre mit der Zieldatenbank verbundenen Anwendungen Ihre Service Level Agreements (SLAs) erfüllen.

Nachdem Sie die Quelldatenbanken ausgeglichen und alle Datenbanken gesichert haben, können Sie Migrationsprozesse aktivieren, die Änderungen in den Zieldatenbanken erkennen und diese vor der Umstellung in die Quelldatenbanken migrieren.

Durch das Erstellen dieser Migrationsprozesse wird dafür gesorgt, dass die Quelldatenbanken synchronisiert und deren Datenstatus auf dem neuesten Stand gehalten wird, nachdem Clients Änderungen an den Zieldatenbanken vorgenommen haben. Ein Fallback kann Tage oder Wochen nach der Umstellung erforderlich sein. Beispielsweise können Clients zum ersten Mal auf Funktionen zugreifen und aufgrund von Fehlern in den Funktionen blockiert werden, die nicht schnell behoben werden können. In diesem Fall können Clients wieder auf den Zugriff auf die Quelldatenbanken umgestellt werden. Bevor die Clients wieder umgestellt werden, müssen alle Änderungen an den Zieldatenbanken in die Quelldatenbanken ausgeglichen werden.

Bei diesem Ansatz müssen einige Umstände besonders beachtet werden:

  • Sie müssen Zielschemas so gestalten, dass eine umgekehrte Migration (von den Ziel- zu den Quelldatenbanken) möglich ist. Wenn Ihr anfänglicher Migrationsprozess (von der Quelle zum Ziel) beispielsweise Joins oder Aggregationen umfasst, ist eine umgekehrte Migration nicht einfach oder sogar unmöglich. In diesem Fall müssen die einzelnen Daten auch in den Zieldatenbanken verfügbar sein.
  • Ein Problem könnte auftreten, wenn die Quelldatenbanken Transaktionslogs haben, in den Zieldatenbanken solch ein nichtfunktionales Feature jedoch nicht bereitgestellt wird. In diesem Fall ist eine umgekehrte Migration (vom Ziel zur Quelle) auf differenzielle Abfragen angewiesen. Diese Einrichtung muss in den Zieldatenbankschemas entwickelt und vorbereitet werden.
  • Clients, die ursprünglich in den Quelldatenbanken ausgeführt wurden, müssen verfügbar und einsatzbereit sein, damit sie in einem Fallback aktiviert werden können. Alle funktionalen Änderungen, die an Clients vorgenommen werden, die auf die Zieldatenbanken zugreifen, müssen auch an den Clients vorgenommen werden, die auf die Quelldatenbank zugreifen, um eine funktionale Äquivalenz zu gewährleisten.

Auch wenn ein Fallback das letzte Mittel ist, ist die Implementierung eines Fallbacks unerlässlich und muss als vollständige Datenbankmigration behandelt werden, die Tests beinhaltet.

Dynamische Änderungen während der Migration

Im Allgemeinen sind Datenbanken dynamische Systeme, da sich Schema- und Datenwerte ändern können. Datenbankschemas können sich nach bestimmten Faktoren, wie zum Beispiel Geschäftsanforderungen, ändern. Datenwerte können sich mit oder unabhängig von Schemaänderungen ändern. Änderungen der Datenwerte können jederzeit mit den entsprechenden Änderungen der Implementierung einer Anwendung erfolgen. In den folgenden Abschnitten werden einige der möglichen Änderungen und ihre Auswirkungen auf eine Datenbankmigration erläutert.

Schemaänderungen

Datenbanken können in Systeme kategorisiert werden, die ein vordefiniertes Schema erfordern oder schemafrei bzw. schemalos sind. Im Allgemeinen unterstützen Systeme, die ein vordefiniertes Schema erfordern, Vorgänge zur Schemaänderung, z. B. das Hinzufügen von Attributen oder Spalten in einem relationalen System.

In diesen Systemen steuern Sie Änderungen über einen Änderungsmanagementprozess. Ein Änderungsmanagementprozess ermöglicht kontrollierte Änderungen. Alle vom Schema abhängigen Vorgänge wie Abfragen oder Datenmigrationsprozesse werden gleichzeitig geändert, um eine konsistente Änderung zu gewährleisten.

Datenbanksysteme, die kein vordefiniertes Schema erfordern, können jederzeit geändert werden. Eine Schemaänderung kann nicht nur von einem autorisierten Nutzer durchgeführt werden. In einigen Fällen ist dies auch programmatisch möglich. In diesen Fällen kann das Schema jederzeit geändert werden. Vorgänge, die vom Schema abhängen, können fehlschlagen, z. B. Abfragen oder Datenmigrationsprozesse. Zur Verhinderung unkontrollierter Schemaänderungen in diesen Datenbanksystemen müssen Sie einen Änderungsmanagementprozess als Konvention und akzeptierte Regel implementieren, statt ihn als Durchsetzung im System durchzuführen.

Datenänderungen

Im Allgemeinen steuern Schemas die möglichen Datenwerte für die verschiedenen Datenattribute. Bei schemalosen Systemen gibt es keine Beschränkungen für Datenwerte.

In beiden Fällen können Datenwerte angezeigt werden, die zuvor nicht gespeichert wurden. Aufzählungstypen werden beispielsweise häufig als eine Reihe von Strings in Datenbanksystemen implementiert. Auf Programmiersprachenebene können diese in Clients als echte Aufzählungstypen implementiert werden, aber nicht unbedingt. Es ist möglich, dass ein Client einen Aufzählungswert als gültig speichert, dieser von anderen Clients jedoch nicht als gültig angesehen wird. Darüber hinaus kann die Funktionalität eines Datenmigrationsprozesses auch auf Aufzählungswerte verzichten. Wenn neue Werte angezeigt werden, schlägt die Datenmigration möglicherweise fehl.

Ein weiteres Beispiel ist die Speicherung von JSON-Strukturen. In vielen Fällen werden JSON-Strukturen in einem Datentyp-String gespeichert. Diese werden jedoch beim Zugriff als JSON-Werte interpretiert. Wenn sich die JSON-Struktur ändert, erkennt das Datenbanksystem dies nicht. Datenmigrationsprozesse, die einen String als JSON-Wert interpretieren, können fehlschlagen.

Änderungen im Migrationsprozess

Das Änderungsmanagement während einer laufenden Datenbankmigration ist schwierig und komplex und kann zu Fehlern bei der Datenmigration oder zu Dateninkonsistenzen führen. Es ist optimal, dass die erforderlichen Änderungen bis zum Ende der Ausgleichsphase verzögert werden, wenn die Quell- und Zieldatenbanksysteme synchronisiert werden. Änderungen zu diesem Zeitpunkt werden dann auf die Zieldatenbanken und deren Clients beschränkt, sofern kein Fallback implementiert wurde.

Wenn Sie den Migrationsprozess während einer Datenmigration ändern müssen, empfehlen wir, die Änderungen auf ein Minimum zu beschränken und eventuell mehrere kleine Änderungen statt einer komplexeren vorzunehmen. Darüber hinaus können Sie diese Änderungen zuerst mithilfe von Testinstanzen Ihrer Quell- und Zieldatenbanken testen. Im Idealfall laden Sie die Testquelle mit Produktionsdaten, die Sie dann zum Testziel migrieren. Mit diesem Ansatz können Sie die vorgeschlagenen Änderungen prüfen, ohne die laufende Produktionsmigration zu beeinträchtigen. Nachdem Sie Ihre Änderungen getestet und geprüft haben, können Sie diese auf Ihr Produktionssystem anwenden.

Damit Änderungen während einer laufenden Datenmigration möglich sind, müssen Sie das Datenmigrationssystem anhalten und neu starten können, möglicherweise mit geänderten Datenmigrationsprozessen. In diesem Fall müssen Sie nicht ganz von vorne mit einer anfänglichen Datenladephase beginnen. Wenn das Datenmigrationssystem eine Funktion für einen Testmigrationslauf unterstützt, können Sie diese auch verwenden.

Wir empfehlen, während der Datenmigration keine Änderungen am Schema, an den Datenwerten oder an den Datenmigrationsprozessen vorzunehmen. Wenn Sie Änderungen vornehmen müssen, können Sie einen Neustart der Datenmigration in Erwägung ziehen, um zu gewährleisten, dass Sie einen definierten Startstatus haben. In jedem Fall ist es äußerst wichtig, dass Sie mit Produktionsdaten testen und Ihre Datenbanken sichern, bevor Sie Änderungen anwenden, damit Sie das Gesamtsystem bei Bedarf auf einen konsistenten Zustand zurücksetzen können.

Minimierung von Migrationsfehlern

Während der Datenbankmigration können unerwartete Probleme auftreten. Im Folgenden werden einige Bereiche aufgeführt, für die eine Vorplanung erforderlich sein kann:

  • Unzureichender Durchsatz. In einem Migrationssystem kann trotz Lasttests nicht genügend Durchsatz vorhanden sein. Dieses Problem kann viele Ursachen haben, z. B. eine unvorhergesehene Ratenerhöhung der Änderungen an der Quelldatenbank oder eine Netzwerkdrosselung. Sie können sich auf diesen Fall vorbereiten und zusätzliche Ressourcen für das dynamische vertikale oder horizontale Skalieren aller betroffenen Komponenten bereitstellen.
  • Datenbankinstabilität. Quell- oder Zieldatenbanken können instabil sein, was die Datenmigration verlangsamen oder den Zugriff zeitweise verhindern kann. Datenmigrationsprozesse müssen möglicherweise häufig wiederhergestellt werden. In diesem Fall könnte eine absichtliche Umstellung für Hochverfügbarkeit oder Notfallwiederherstellung das Problem beheben. Durch eine Umstellung wird die nichtfunktionale Umgebung (Maschinen und Speicher) geändert und das Problem möglicherweise behoben. In diesem Fall müssen Sie die Umstellung und die Wiederherstellungsprozesse der Datenbankmigration testen, um zu gewährleisten, dass die Umstellung keine Dateninkonsistenzen in den Zieldatenbanken verursacht.
  • Ausschöpfung der Dateigröße für Transaktionslogs. In einigen Fällen werden Transaktionslogs in Dateien gespeichert, die eine Obergrenze haben. Es ist möglich, dass diese Obergrenze erreicht wird und die Datenbankmigration dann fehlschlägt. Es ist wichtig, zu verstehen, welche Teile eines Datenbanksystems dynamisch neu konfiguriert werden können, um auftretende Ressourcenbeschränkungen zu beheben. Wenn bestimmte Aspekte nicht dynamisch konfiguriert werden können, muss die anfängliche Größe sorgfältig bestimmt werden.

Je realistischer und vollständiger Sie die Vorabtests gestalten, desto wahrscheinlicher finden Sie mögliche Probleme, die Sie im Voraus beheben können.

Weitere Informationen