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ärem 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 möglichst wenig gestört werden, sollte dies ein gut geplantes und koordiniertes Verfahren sein.
Es gibt zwei verschiedene empfohlene Lösungen für die Anwendungsmigration: die blaugrüne Cut-Over-Strategie und die Canary-Cutover-Strategie. In den folgenden Abschnitten werden diese Strategien ausführlicher beschrieben.
Blau-grüne Strategie — Mit diesem Ansatz stellen Sie Ihre Anwendung so um, dass sie Amazon Keyspaces als primären Datenspeicher und Cassandra als sekundären Datenspeicher in einem einzigen Schritt behandelt. Dazu können Sie ein AWS AppConfig Feature-Flag verwenden, um die Auswahl von primären und sekundären Datenspeichern in der gesamten 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, stellen 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 um. Nach der Umstellung überwachen und vergleichen Sie die Ergebnisse weiter, wie im Abschnitt zur Datenvalidierung beschrieben, um die Konsistenz zwischen beiden Datenbanken sicherzustellen, bevor Sie Cassandra außer Betrieb nehmen.
Wenn Sie Probleme feststellen, können Sie schnell zum vorherigen Status zurückkehren, indem Sie zu Cassandra als primärem 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.
Kanarische Strategie — Bei diesem Ansatz führen Sie die Migration schrittweise auf eine Teilmenge Ihrer Benutzer oder Ihres Datenverkehrs aus. Anfänglich wird ein kleiner Teil des Datenverkehrs Ihrer Anwendung, z. B. 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 realem Datenverkehr testen, deren Leistung und Stabilität überwachen und mögliche Probleme untersuchen. Wenn Sie keine Probleme feststellen, können Sie den Prozentsatz des Datenverkehrs, der an Amazon Keyspaces weitergeleitet wird, schrittweise erhöhen, bis dieser zum primären Datenspeicher für alle Benutzer und den gesamten Datenverkehr wird.
Dieser schrittweise Rollout minimiert das Risiko weit verbreiteter Serviceunterbrechungen und ermöglicht einen kontrollierteren Migrationsprozess. Wenn während der Bereitstellung auf Canary kritische Probleme auftreten, können Sie schnell zur vorherigen Version zurückkehren, indem Sie Cassandra als primären Datenspeicher für das betroffene Verkehrssegment 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.
