Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Migration der Anwendung während einer Online-Migration
In der vierten Phase einer Online-Migration migrieren Sie Ihre Anwendung und wechseln zu Amazon Keyspaces als primären Datenspeicher. Das bedeutet, dass Sie Ihre Anwendung so umstellen, dass sie direkt von und zu Amazon Keyspaces liest und schreibt. Um sicherzustellen, dass Ihre Benutzer nur minimal gestört werden, sollte dies ein gut geplanter und koordinierter Prozess sein.
Es gibt zwei verschiedene empfohlene Lösungen für die Anwendungsmigration: die blau-grüne Cut-Over-Strategie und die Canary-Cut-Over-Strategie. In den folgenden Abschnitten werden diese Strategien detaillierter beschrieben.
Blau-grüne Strategie — Mit diesem Ansatz stellen Sie Ihre Anwendung in einem einzigen Schritt so um, dass Amazon Keyspaces als primären Datenspeicher und Cassandra als sekundären Datenspeicher behandelt werden. Dazu können Sie ein AWS AppConfig Feature-Flag verwenden, um die Auswahl der primären und sekundären Datenspeicher in der Anwendungsinstanz zu steuern. Weitere Informationen zu Feature-Flags finden Sie unter Erstellen eines Feature-Flag-Konfigurationsprofils in AWS AppConfig.
Nachdem Sie Amazon Keyspaces zum primären Datenspeicher gemacht haben, überwachen Sie das Verhalten und die Leistung der Anwendung und stellen so sicher, dass Amazon Keyspaces Ihre Anforderungen erfüllt und die Migration erfolgreich ist.
Wenn Sie beispielsweise Dual-Reads für Ihre Anwendung implementiert haben, übertragen Sie während der Anwendungsmigrationsphase die primären Lesevorgänge von Cassandra auf Amazon Keyspaces und die sekundären Lesevorgänge von Amazon Keyspaces auf Cassandra. Nach der Umstellung überwachen und vergleichen Sie die Ergebnisse weiterhin, wie im Abschnitt zur Datenvalidierung beschrieben, um die Konsistenz beider Datenbanken sicherzustellen, bevor Cassandra außer Betrieb genommen wird.
Wenn Sie Probleme feststellen, können Sie schnell zum vorherigen Zustand zurückkehren, indem Sie zu Cassandra als primären Datenspeicher zurückkehren. Sie fahren nur dann mit der Außerbetriebnahmephase der Migration fort, wenn Amazon Keyspaces alle Ihre Anforderungen als primärer Datenspeicher erfüllt.
Canary-Strategie — Bei diesem Ansatz führen Sie die Migration schrittweise auf eine Teilmenge Ihrer Benutzer oder Ihres Datenverkehrs aus. Anfänglich wird ein kleiner Prozentsatz des Datenverkehrs Ihrer Anwendung, beispielsweise 5% des gesamten Datenverkehrs, an die Version weitergeleitet, die Amazon Keyspaces als primären Datenspeicher verwendet, während der Rest des Datenverkehrs weiterhin Cassandra als primären Datenspeicher verwendet.
Auf diese Weise können Sie die migrierte Version gründlich mit echtem Datenverkehr testen und ihre Leistung und Stabilität überwachen und potenzielle Probleme untersuchen. Wenn Sie keine Probleme feststellen, können Sie den Prozentsatz des Datenverkehrs, der zu Amazon Keyspaces weitergeleitet wird, schrittweise erhöhen, bis er zum primären Datenspeicher für alle Benutzer und den gesamten Datenverkehr wird.
Diese schrittweise Einführung minimiert das Risiko weit verbreiteter Serviceunterbrechungen und ermöglicht einen kontrollierteren Migrationsprozess. Sollten während der Bereitstellung von Canary kritische Probleme auftreten, können Sie schnell zur vorherigen Version zurückkehren, indem Sie Cassandra als primären Datenspeicher für das betroffene Traffic-Segment verwenden. Sie fahren erst mit der Außerbetriebnahmephase der Migration fort, nachdem Sie bestätigt haben, dass Amazon Keyspaces 100% Ihrer Benutzer und Ihres Datenverkehrs erwartungsgemäß verarbeitet.
Das folgende Diagramm veranschaulicht die einzelnen Schritte der Canary-Strategie.
