Überschneiden

Die Strategie für die Datenbank-Cutover ist in der Regel eng mit den Anforderungen an die Ausfallzeiten für die Anwendung verbunden. Zu den Strategien, die Sie für den Datenbank-Cutover verwenden können, gehören Offline-Migration, Flash-Cut-Migration, aktive/aktive Datenbankkonfiguration und inkrementelle Migration. Diese werden in den folgenden Abschnitten erläutert.

Offline-Migration

Wenn Sie Ihre Anwendung während Schreibvorgängen über einen längeren Zeitraum offline schalten können, können SieAWS DMSEinstellungen für Volllastaufgaben oder eine der Offline-Migrationsoptionen für Ihre Datenmigration. Der Leseverkehr kann fortgesetzt werden, während diese Migration läuft, der Schreibdatenverkehr muss jedoch gestoppt werden. Da alle Daten aus der Quelldatenbank kopiert werden müssen, werden Quelldatenbankressourcen wie I/O und CPU genutzt.

Grundsätzlich umfasst die Offline-Migration folgende Schritte:

1. Schließen Sie die Schemakonvertierung ab

2. Starten Sie Ausfallzeiten für Schreibverkehr.

3. Migrieren Sie die Daten mit einer der Offline-Migrationsoptionen.

4. Überprüfen Ihrer Daten.

5. Richten Sie Ihre Anwendung auf die neue Datenbank.

6. Beenden Sie die Ausfallzeit der Anwendung.

Flash-Cut-Migration

Bei der Flash-Cut-Migration besteht das Hauptziel darin, die Ausfallzeiten auf ein Minimum zu beschränken. Diese Strategie beruht auf der kontinuierlichen Datenreplikation (CDC) von der Quelldatenbank in die Zieldatenbank. Der gesamte Lese-/Schreibverkehr wird in der aktuellen Datenbank fortgesetzt, während die Daten migriert werden. Da alle Daten aus der Quelldatenbank kopiert werden müssen, werden Quellserverressourcen wie I/O und CPU genutzt. Sie sollten testen, um sicherzustellen, dass diese Datenmigrationsaktivität keine Auswirkungen auf Ihre Anwendungsleistungs-SLAs hat.

Grundsätzlich umfasst die Flash-Cut-Migration folgende Schritte:

1. Schließen Sie die Schemakonvertierung ab

2. EinrichtenAWS DMSim kontinuierlichen Datenreplikationsmodus.

3. Überprüfen Sie die Daten, wenn die Quell- und Zieldatenbanken synchronisiert sind.

4. Starten Sie die Ausfallzeit der Anwendung.

5. Rollen Sie die neue Version der Anwendung aus, die auf die neue Datenbank verweist.

6. Beenden Sie die Ausfallzeit der Anwendung.

Aktive/aktive Datenbankkonfiguration

Die aktive/aktive Datenbankkonfiguration beinhaltet das Einrichten eines Mechanismus, um die Quell- und Zieldatenbanken synchron zu halten, während beide Datenbanken für Schreibverkehr verwendet werden. Diese Strategie beinhaltet mehr Arbeit als Offline- oder Flash-Cut-Migration, bietet aber auch mehr Flexibilität während der Migration. Beispielsweise können Sie nicht nur minimale Ausfallzeiten während der Migration feststellen, sondern auch Ihren Produktionsverkehr in kleinen, kontrollierten Chargen in die neue Datenbank verschieben, anstatt einen einmaligen Cutover durchzuführen. Sie können entweder duale Schreibvorgänge ausführen, damit Änderungen an beiden Datenbanken vorgenommen werden, oder ein bidirektionales Replikationstool wieHVRum die Datenbanken synchron zu halten. Diese Strategie hat eine höhere Komplexität in Bezug auf Einrichtung und Wartung, daher sind weitere Tests erforderlich, um Probleme mit der Datenkonsistenz zu vermeiden.

Grundsätzlich umfasst die Aktive/aktive Datenbankkonfiguration folgende Schritte:

1. Schließen Sie die Schemakonvertierung ab

2. Kopieren Sie die vorhandenen Daten aus der Quelldatenbank in die Zieldatenbank und halten Sie dann die beiden Datenbanken synchron, indem Sie ein bidirektionales Replikationstool oder duale Schreibvorgänge aus der Anwendung verwenden.

3. Überprüfen Sie die Daten, wenn die Quell- und Zieldatenbanken synchronisiert sind.

4. Verschieben Sie eine Teilmenge Ihres Datenverkehrs in die neue Datenbank.

5. Verschieben Sie den Datenverkehr weiter, bis Ihr gesamter Datenbankverkehr in die neue Datenbank verschoben wurde.

Inkrementelle Migration

Bei der inkrementellen Migration migrieren Sie Ihre Anwendung in kleinere Teile, anstatt einen einmaligen, vollständigen Cutover durchzuführen. Diese Cutover-Strategie könnte viele Variationen haben, basierend auf Ihrer aktuellen Anwendungsarchitektur oder dem Refactoring, das Sie in der Anwendung durchführen möchten.

Sie können eineEntwurfs-Musterum neue unabhängige Microservices hinzuzufügen, um Teile einer bestehenden, monolithischen Legacy-Anwendung zu ersetzen. Diese unabhängigen Microservices haben ihre eigenen Tabellen, die von keinem anderen Teil der Anwendung freigegeben oder darauf zugegriffen werden. Sie migrieren diese Microservices nacheinander in die neue Datenbank, indem Sie eine der anderen Cutover-Strategien verwenden. Die migrierten Microservices verwenden die neue Datenbank für Lese-/Schreibdatenverkehr, während alle anderen Teile der Anwendung weiterhin die alte Datenbank verwenden. Wenn alle Microservices migriert wurden, setzen Sie Ihre Legacy-Anwendung außer Betrieb. Diese Strategie zerlegt die Migration in kleinere, überschaubare Teile und kann daher die Risiken verringern, die mit einer großen Migration verbunden sind.