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.
# Online-Migration zu Amazon Keyspaces: Strategien und bewährte Methoden
Wenn Sie die Anwendungsverfügbarkeit während einer Migration von Apache Cassandra zu Amazon Keyspaces aufrechterhalten müssen, können Sie eine benutzerdefinierte Online-Migrationsstrategie vorbereiten, indem Sie die in diesem Thema beschriebenen Schlüsselkomponenten implementieren. Wenn Sie diese bewährten Methoden für Online-Migrationen befolgen, können Sie sicherstellen, dass die Verfügbarkeit und read-after-write Konsistenz der Anwendungen während des gesamten Migrationsprozesses erhalten bleibt, wodurch die Auswirkungen auf Ihre Benutzer minimiert werden.
Bei der Entwicklung einer Online-Migrationsstrategie von Apache Cassandra zu Amazon Keyspaces müssen Sie die folgenden wichtigen Schritte berücksichtigen.
1. **Neue Daten schreiben**
+ **ZDM Dual Write Proxy für Amazon Keyspaces-Migration** — Verwenden Sie den auf [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) verfügbaren ZDM Dual Write Proxy, um eine Migration ohne Ausfallzeiten von Apache Cassandra zu Amazon Keyspaces durchzuführen. Der ZDM Proxy führt duale Schreibvorgänge durch, ohne dass bestehende Anwendungen umgestaltet werden müssen, und führt duale Lesevorgänge zur Abfragevalidierung durch.
+ Doppelte Schreibvorgänge für Anwendungen: Sie können duale Schreibvorgänge in Ihrer Anwendung mithilfe vorhandener Cassandra-Clientbibliotheken und -Treiber implementieren. Benennen Sie eine Datenbank als Leader und die andere als Nachfolger. Schreibfehler in die Follower-Datenbank werden zur Analyse in einer [Warteschlange (Dead Letter Queue, DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) aufgezeichnet.
+ Dual-Writes auf Messaging-Ebene: Alternativ können Sie Ihre bestehende Messaging-Plattform so konfigurieren, dass Schreibvorgänge über einen zusätzlichen Verbraucher sowohl an Cassandra als auch an Amazon Keyspaces gesendet werden. Dadurch entstehen letztlich konsistente Ansichten in beiden Datenbanken.
1. **Migration historischer Daten**
+ Historische Daten kopieren: Sie können historische Daten mithilfe AWS Glue von benutzerdefinierten ETL-Skripts (Extrahieren, Transformieren und Laden) von Cassandra zu Amazon Keyspaces migrieren. Bewältigen Sie die Konfliktlösung zwischen dualen Schreibvorgängen und Massenladevorgängen mithilfe von Techniken wie einfachen Transaktionen oder Zeitstempeln.
+ Verwendung Time-To-Live (TTL): Für kürzere Aufbewahrungsfristen können Sie TTL sowohl in Cassandra als auch in Amazon Keyspaces verwenden, um zu vermeiden, dass unnötige historische Daten hochgeladen werden. Da alte Daten in Cassandra ablaufen und neue Daten per Dual-Write-Verfahren geschrieben werden, holt Amazon Keyspaces irgendwann auf.
1. **Daten werden validiert**
+ Duale Lesevorgänge: Implementieren Sie duale Lesevorgänge aus den Datenbanken Cassandra (primär) und Amazon Keyspaces (sekundär) und vergleichen Sie die Ergebnisse asynchron. Unterschiede werden protokolliert oder an eine DLQ gesendet.
+ Lesevorgänge an Stichproben: Verwenden Sie Λ -Funktionen, um in regelmäßigen Abständen Daten aus beiden Systemen abzutasten und zu vergleichen, wobei alle Abweichungen in einem DLQ protokolliert werden.
1. **Die Anwendung wird migriert**
+ Blau-grüne Strategie: Stellen Sie Ihre Anwendung so um, dass sie Amazon Keyspaces als primären und Cassandra als sekundären Datenspeicher in einem einzigen Schritt behandelt. Überwachen Sie die Leistung und führen Sie bei Problemen einen Rollback durch.
+ Bereitstellung auf Kanaren: Führen Sie die Migration schrittweise zunächst für eine Untergruppe von Benutzern durch und erhöhen Sie schrittweise den Traffic zu Amazon Keyspaces als primärem Benutzer, bis die Migration vollständig abgeschlossen ist.
1. **Außerbetriebnahme von Cassandra**
Sobald Ihre Anwendung vollständig zu Amazon Keyspaces migriert und die Datenkonsistenz validiert ist, können Sie die Außerbetriebnahme Ihres Cassandra-Clusters auf der Grundlage von Datenaufbewahrungsrichtlinien planen.
Durch die Planung einer Online-Migrationsstrategie mit diesen Komponenten können Sie reibungslos und mit minimalen Ausfallzeiten oder Unterbrechungen auf den vollständig verwalteten Amazon Keyspaces-Service umsteigen. In den folgenden Abschnitten werden die einzelnen Komponenten ausführlicher behandelt.
**Topics**
+ [Schreiben neuer Daten während einer Online-Migration](migration-online-dw.md)
+ [Upload historischer Daten während einer Online-Migration](migration-online-historical.md)
+ [Überprüfung der Datenkonsistenz während einer Online-Migration](migration-online-validation.md)
+ [Migration der Anwendung während einer Online-Migration](migration-online-app-migration.md)
+ [Außerbetriebnahme von Cassandra nach einer Online-Migration](migration-online-decommission.md)
# Schreiben neuer Daten während einer Online-Migration
Der erste Schritt in einem Online-Migrationsplan besteht darin, sicherzustellen, dass alle neuen Daten, die von der Anwendung geschrieben werden, in beiden Datenbanken, Ihrem vorhandenen Cassandra-Cluster und Amazon Keyspaces, gespeichert werden. Ziel ist es, einen konsistenten Überblick über die beiden Datenspeicher zu bieten. Sie können dies tun, indem Sie alle neuen Schreibvorgänge auf beide Datenbanken anwenden. Um duale Schreibvorgänge zu implementieren, sollten Sie eine der folgenden drei Optionen in Betracht ziehen.
+ **ZDM Dual Write Proxy für Amazon Keyspaces-Migration** — Mit dem auf [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) verfügbaren ZDM-Proxy für Amazon Keyspaces können Sie Ihre Apache Cassandra-Workloads ohne Anwendungsausfälle zu Amazon Keyspaces migrieren. Diese erweiterte Lösung implementiert AWS bewährte Verfahren und erweitert die offiziellen ZDM-Proxy-Funktionen.
+ Führen Sie Online-Migrationen zwischen Apache Cassandra und Amazon Keyspaces durch.
+ Schreiben Sie Daten gleichzeitig in Quell- und Zieltabellen, ohne Anwendungen umzugestalten.
+ Überprüfen Sie Abfragen mithilfe von Dual-Read-Vorgängen.
Die Lösung bietet die folgenden Verbesserungen für die Arbeit mit AWS Amazon Keyspaces.
+ **Container-Bereitstellung** — Verwenden Sie ein vorkonfiguriertes Docker-Image aus Amazon Elastic Container Registry (Amazon ECR) für VPC-zugängliche Bereitstellungen.
+ **Infrastruktur als Code** — Implementieren Sie mithilfe AWS CloudFormation von Vorlagen für die automatische Einrichtung auf. AWS Fargate
+ **Amazon Keyspaces-Kompatibilität — Greifen** Sie auf Systemtabellen mit benutzerdefinierten Anpassungen für Amazon Keyspaces zu.
Die Lösung läuft auf Amazon ECS mit Fargate und bietet serverlose Skalierbarkeit auf der Grundlage Ihrer Workload-Anforderungen. Ein Network Load Balancer verteilt den eingehenden Anwendungsdatenverkehr auf mehrere Amazon ECS-Aufgaben, um eine hohe Verfügbarkeit zu gewährleisten.
![\[Implementierung des ZDM-Dual-Write-Proxys für die Migration von Daten von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Doppelte Schreibvorgänge für Anwendungen** — Sie können duale Schreibvorgänge mit minimalen Änderungen an Ihrem Anwendungscode implementieren, indem Sie die vorhandenen Cassandra-Clientbibliotheken und -Treiber nutzen. Sie können entweder duale Schreibvorgänge in Ihrer vorhandenen Anwendung implementieren oder eine neue Ebene in der Architektur für duale Schreibvorgänge erstellen. Weitere Informationen und eine Kundenfallstudie, die zeigt, wie duale Schreibvorgänge in einer bestehenden Anwendung implementiert wurden, finden Sie in der [Fallstudie zur Cassandra-Migration](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Bei der Implementierung von dualen Schreibvorgängen können Sie eine Datenbank als Leader und die andere Datenbank als Follower-Datenbank festlegen. Auf diese Weise können Sie weiterhin in Ihre ursprüngliche Quell- oder Leader-Datenbank schreiben, ohne dass Schreibfehler in die Follower- oder Zieldatenbank den kritischen Pfad Ihrer Anwendung stören.
Anstatt fehlgeschlagene Schreibvorgänge an den Follower erneut zu versuchen, können Sie Amazon Simple Queue Service verwenden, um fehlgeschlagene Schreibvorgänge in einer [Warteschlange für tote Briefe (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) aufzuzeichnen. Mit dem DLQ können Sie die fehlgeschlagenen Schreibvorgänge an den Follower analysieren und feststellen, warum die Verarbeitung in der Zieldatenbank nicht erfolgreich war.
Für eine anspruchsvollere Dual-Write-Implementierung können Sie sich an AWS bewährte Methoden für den Entwurf einer Sequenz lokaler Transaktionen unter Verwendung des [Saga-Musters](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html) halten. Ein Saga-Muster stellt sicher, dass, falls eine Transaktion fehlschlägt, die Saga Ausgleichstransaktionen ausführt, um die durch die vorherigen Transaktionen vorgenommenen Datenbankänderungen rückgängig zu machen.
Wenn Sie Dual-Writes für eine Online-Migration verwenden, können Sie die Dual-Writes nach dem Saga-Muster konfigurieren, sodass jeder Schreibvorgang eine lokale Transaktion ist, um atomare Operationen in heterogenen Datenbanken sicherzustellen. Weitere Informationen zum Entwerfen verteilter Anwendungen mithilfe der empfohlenen Entwurfsmuster für die AWS Cloud finden Sie unter [Cloud-Entwurfsmuster, Architekturen](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction) und Implementierungen.
![\[Implementierung von dualen Schreibvorgängen auf Anwendungsebene bei der Migration von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Doppelte Schreibvorgänge auf Messaging-Tier** — Anstatt duale Schreibvorgänge auf Anwendungsebene zu implementieren, können Sie Ihre bestehende Messaging-Stufe verwenden, um duale Schreibvorgänge auf Cassandra und Amazon Keyspaces durchzuführen.
Zu diesem Zweck können Sie für Ihre Messaging-Plattform einen zusätzlichen Verbraucher konfigurieren, der Schreibvorgänge an beide Datenspeicher sendet. Dieser Ansatz bietet eine einfache Low-Code-Strategie, bei der mithilfe der Messaging-Ebene zwei Ansichten für beide Datenbanken erstellt werden, die letztendlich konsistent sind.
# Upload historischer Daten während einer Online-Migration
Nach der Implementierung von Dual Writes, um sicherzustellen, dass neue Daten in Echtzeit in beide Datenspeicher geschrieben werden, besteht der nächste Schritt im Migrationsplan darin, zu bewerten, wie viele historische Daten Sie kopieren oder massenweise von Cassandra nach Amazon Keyspaces hochladen müssen. Dadurch wird sichergestellt, dass sowohl neue Daten als auch historische Daten in der neuen Amazon Keyspaces-Datenbank verfügbar sind, bevor Sie die Anwendung migrieren.
Abhängig von Ihren Anforderungen an die Datenspeicherung, z. B. davon, wie viele historische Daten Sie gemäß den Richtlinien Ihrer Organisation aufbewahren müssen, können Sie eine der folgenden beiden Optionen in Betracht ziehen.
+ **Massen-Upload historischer Daten** — Die Migration historischer Daten aus Ihrer bestehenden Cassandra-Bereitstellung zu Amazon Keyspaces kann durch verschiedene Techniken erreicht werden, z. B. durch die Verwendung von AWS Glue benutzerdefinierten Skripten zum Extrahieren, Transformieren und Laden (ETL) der Daten. Weitere Informationen zur Verwendung AWS Glue zum Hochladen historischer Daten finden Sie unter. [Offline-Migrationsprozess: Apache Cassandra zu Amazon Keyspaces](migrating-offline.md)
Wenn Sie den Massenupload historischer Daten planen, müssen Sie berücksichtigen, wie Konflikte gelöst werden können, die auftreten können, wenn neue Schreibvorgänge versuchen, dieselben Daten zu aktualisieren, die gerade hochgeladen werden. Es wird davon ausgegangen, dass der Bulk-Upload irgendwann konsistent sein wird, was bedeutet, dass die Daten irgendwann alle Knoten erreichen werden.
Wenn dieselben Daten aufgrund eines neuen Schreibvorgangs gleichzeitig aktualisiert werden, sollten Sie sicherstellen, dass sie nicht durch den Upload historischer Daten überschrieben werden. Um sicherzustellen, dass Sie die neuesten Aktualisierungen Ihrer Daten auch während des Massenimports beibehalten, müssen Sie die Konfliktlösung entweder in die Bulk-Upload-Skripts oder in die Anwendungslogik für duale Schreibvorgänge integrieren.
Beispielsweise können Sie [Einfache Transaktionen](functional-differences.md#functional-differences.light-transactions) (LWT) verwenden, um Operationen zu vergleichen und festzulegen. Zu diesem Zweck können Sie Ihrem Datenmodell ein zusätzliches Feld hinzufügen, das den Zeitpunkt der Änderung oder den Status angibt.
Darüber hinaus unterstützt Amazon Keyspaces die `WRITETIME` Cassandra-Timestamp-Funktion. Sie können clientseitige Zeitstempel von Amazon Keyspace verwenden, um Zeitstempel der Quelldatenbank beizubehalten und Konfliktlösung zu implementieren. last-writer-wins Weitere Informationen finden Sie unter [Clientseitige Zeitstempel in Amazon Keyspaces](client-side-timestamps.md).
+ **Verwenden von Time-to-Live (TTL)** — Für Datenaufbewahrungszeiträume von weniger als 30, 60 oder 90 Tagen können Sie TTL in Cassandra und Amazon Keyspaces während der Migration verwenden, um zu vermeiden, dass unnötige historische Daten zu Amazon Keyspaces hochgeladen werden. TTL ermöglicht es Ihnen, einen Zeitraum festzulegen, nach dem die Daten automatisch aus der Datenbank entfernt werden.
Anstatt historische Daten in Amazon Keyspaces zu kopieren, können Sie während der Migrationsphase die TTL-Einstellungen so konfigurieren, dass die historischen Daten im alten System (Cassandra) automatisch ablaufen, während die neuen Schreibvorgänge nur mit der Dual-Write-Methode auf Amazon Keyspaces angewendet werden. Im Laufe der Zeit und da alte Daten im Cassandra-Cluster ständig ablaufen und neue Daten mit der Dual-Write-Methode geschrieben wurden, holt Amazon Keyspaces automatisch auf und enthält dieselben Daten wie Cassandra.
Dieser Ansatz kann die Menge der zu migrierenden Daten erheblich reduzieren, was zu einem effizienteren und optimierten Migrationsprozess führt. Sie können diesen Ansatz in Betracht ziehen, wenn Sie mit großen Datensätzen mit unterschiedlichen Anforderungen an die Datenspeicherung arbeiten. Weitere Informationen zu TTL finden Sie unter [Daten mit Time to Live (TTL) für Amazon Keyspaces (für Apache Cassandra) ablaufen lassen](TTL.md).
Betrachten Sie das folgende Beispiel für eine Migration von Cassandra zu Amazon Keyspaces mit TTL-Datenablaufzeit. In diesem Beispiel setzen wir TTL für beide Datenbanken auf 60 Tage und zeigen, wie der Migrationsprozess über einen Zeitraum von 90 Tagen voranschreitet. Beide Datenbanken empfangen in diesem Zeitraum dieselben neu geschriebenen Daten mithilfe der Dual-Write-Methode. Wir werden uns drei verschiedene Phasen der Migration ansehen, jede Phase dauert 30 Tage.
Wie der Migrationsprozess für jede Phase funktioniert, wird in den folgenden Bildern gezeigt.
![\[Verwendung von TTL zum Ablaufen historischer Daten bei der Migration von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Nach den ersten 30 Tagen haben der Cassandra-Cluster und Amazon Keyspaces neue Schreibvorgänge erhalten. Der Cassandra-Cluster enthält auch historische Daten, deren Aufbewahrungsfrist von 60 Tagen noch nicht erreicht wurde, was 50% der Daten im Cluster ausmacht.
Daten, die älter als 60 Tage sind, werden im Cassandra-Cluster automatisch mithilfe von TTL gelöscht. Derzeit enthält Amazon Keyspaces 50% der im Cassandra-Cluster gespeicherten Daten, die sich aus den neuen Schreibvorgängen abzüglich der historischen Daten zusammensetzen.
1. Nach 60 Tagen enthalten sowohl der Cassandra-Cluster als auch Amazon Keyspaces dieselben Daten, die in den letzten 60 Tagen geschrieben wurden.
1. Innerhalb von 90 Tagen enthalten Cassandra und Amazon Keyspaces dieselben Daten und laufen mit derselben Geschwindigkeit ab.
Dieses Beispiel zeigt, wie der Schritt des Hochladens historischer Daten vermieden werden kann, indem TTL mit einem Ablaufdatum von 60 Tagen verwendet wird.
# Überprüfung der Datenkonsistenz während einer Online-Migration
Der nächste Schritt im Online-Migrationsprozess ist die Datenvalidierung. Durch duale Schreibvorgänge werden Ihrer Amazon Keyspaces-Datenbank neue Daten hinzugefügt, und Sie haben die Migration historischer Daten entweder per Bulk-Upload oder Datenablauf mit TTL abgeschlossen.
Jetzt können Sie die Überprüfungsphase nutzen, um zu bestätigen, dass beide Datenspeicher tatsächlich dieselben Daten enthalten, und dieselben Leseergebnisse zurückgeben. Sie können eine der folgenden beiden Optionen wählen, um zu überprüfen, ob Ihre beiden Datenbanken identische Daten enthalten.
+ **Doppelte Lesevorgänge** — Um zu überprüfen, ob sowohl die Quell- als auch die Zieldatenbank denselben Satz neu geschriebener und historischer Daten enthalten, können Sie duale Lesevorgänge implementieren. Dazu lesen Sie ähnlich wie bei der dualen Schreibmethode sowohl aus Ihrer primären Cassandra- als auch aus Ihrer sekundären Amazon Keyspaces-Datenbank und vergleichen die Ergebnisse asynchron.
Die Ergebnisse aus der Primärdatenbank werden an den Client zurückgegeben, und die Ergebnisse aus der sekundären Datenbank werden zur Validierung anhand der primären Ergebnismenge verwendet. Die gefundenen Unterschiede können protokolliert oder zur späteren Abstimmung an eine [Warteschlange für unzustellbare Briefe (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) gesendet werden.
In der folgenden Abbildung führt die Anwendung einen synchronen Lesevorgang aus Cassandra (dem primären Datenspeicher) und einen asynchronen Lesevorgang aus Amazon Keyspaces, dem sekundären Datenspeicher, durch.
![\[Verwendung von dualen Lesevorgängen zur Überprüfung der Datenkonsistenz während einer Online-Migration von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Lesevorgänge an Stichproben** — Eine alternative Lösung, die keine Änderungen am Anwendungscode erfordert, besteht darin, AWS Lambda Funktionen zu verwenden, um regelmäßig und nach dem Zufallsprinzip Daten sowohl aus dem Cassandra-Quellcluster als auch aus der Amazon Keyspaces-Zieldatenbank auszuwählen.
Diese Lambda-Funktionen können so konfiguriert werden, dass sie in regelmäßigen Abständen ausgeführt werden. Die Lambda-Funktion ruft eine zufällige Teilmenge von Daten sowohl vom Quell- als auch vom Zielsystem ab und führt dann einen Vergleich der Stichprobendaten durch. Alle Diskrepanzen oder Nichtübereinstimmungen zwischen den beiden Datensätzen können aufgezeichnet und zur späteren Abstimmung an eine spezielle Warteschlange ([Dead Letter](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) Queue, DLQ) gesendet werden.
Dieser Prozess wird im folgenden Diagramm veranschaulicht.
![\[Verwendung von Probenlesevorgängen zur Überprüfung der Datenkonsistenz während und Online-Migration von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# 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](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
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](migration-online-validation.md) 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.
![\[Verwendung der blaugrünen Strategie für die Migration einer Anwendung von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **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.
Diese schrittweise Einführung 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.
![\[Verwendung der kanarischen Strategie für die Migration einer Anwendung von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Außerbetriebnahme von Cassandra nach einer Online-Migration
Nachdem die Anwendungsmigration abgeschlossen ist und Ihre Anwendung vollständig auf Amazon Keyspaces läuft und Sie die Datenkonsistenz über einen bestimmten Zeitraum überprüft haben, können Sie die Außerbetriebnahme Ihres Cassandra-Clusters planen. Während dieser Phase können Sie beurteilen, ob die in Ihrem Cassandra-Cluster verbleibenden Daten archiviert werden müssen oder gelöscht werden können. Dies hängt von den Richtlinien Ihres Unternehmens für den Umgang und die Aufbewahrung von Daten ab.
Wenn Sie bei der Planung Ihrer Online-Migration von Cassandra zu Amazon Keyspaces diese Strategie befolgen und die in diesem Thema beschriebenen empfohlenen Best Practices berücksichtigen, können Sie einen reibungslosen Übergang zu Amazon Keyspaces sicherstellen und gleichzeitig die read-after-write Konsistenz und Verfügbarkeit Ihrer Anwendung wahren.
Die Migration von Apache Cassandra zu Amazon Keyspaces kann zahlreiche Vorteile bieten, darunter einen geringeren Betriebsaufwand, automatische Skalierung, verbesserte Sicherheit und ein Framework, das Ihnen hilft, Ihre Compliance-Ziele zu erreichen. Durch die Planung einer Online-Migrationsstrategie mit dualem Schreibvorgang, Upload historischer Daten, Datenvalidierung und schrittweiser Einführung können Sie einen reibungslosen Übergang mit minimalen Unterbrechungen für Ihre Anwendung und deren Benutzer sicherstellen.
Die Implementierung der in diesem Thema erörterten Online-Migrationsstrategie ermöglicht es Ihnen, die Migrationsergebnisse zu überprüfen, Probleme zu identifizieren und zu beheben und letztendlich Ihre bestehende Cassandra-Bereitstellung zugunsten des vollständig verwalteten Amazon Keyspaces-Service außer Betrieb zu nehmen.