View a markdown version of this page

Failback - Amazon Managed Streaming für Apache Kafka

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.

Failback

Sie können ein Failback zur primären AWS Region durchführen, nachdem das Serviceereignis in dieser Region beendet ist.

Identical topic name replication

  1. Erstellen Sie einen neuen MSK Replicator mit Ihrem sekundären Cluster als Quelle und primärem Cluster als Ziel, wobei die Startposition auf die früheste und identische Themenreplikation festgelegt ist (behalten Sie denselben Themennamen in der Konsole bei). Dadurch werden alle Daten, die nach dem Failover in den sekundären Cluster geschrieben wurden, zurück in die primäre Region kopiert.

  2. Überwachen Sie die MessageLag Metrik auf dem neuen Replikator in Amazon, CloudWatch bis sie den Wert erreicht hat0, was bedeutet, dass alle Daten vom sekundären zum primären repliziert wurden.

  3. Nachdem alle Daten repliziert wurden, beenden Sie alle Produzenten, die eine Verbindung zum sekundären Cluster herstellen, und starten Sie, dass die Produzenten eine Verbindung zum primären Cluster herstellen.

  4. Warten Sie, bis die MaxOffsetLag Metrik erreicht ist, bis Ihre Verbraucher eine Verbindung zum sekundären Cluster hergestellt haben0, um sicherzustellen, dass sie alle Daten verarbeitet haben. Siehe Überwachen Sie die Verzögerungen bei den Verbrauchern.

  5. Sobald alle Daten verarbeitet wurden, beenden Sie die Verbraucher in der sekundären Region und starten Sie die Verbindung der Verbraucher zum primären Cluster, um das Failback abzuschließen.

  6. Löschen Sie den Replikator, den Sie im ersten Schritt erstellt haben und der Daten von Ihrem sekundären Cluster auf den primären Cluster repliziert.

  7. Stellen Sie sicher, dass Ihr vorhandener Replicator, der Daten vom primären zum sekundären Cluster kopiert, den Status „LÄUFT“ hat und die ReplicatorThroughput Metrik in Amazon größer als CloudWatch 0 ist.

    Beachten Sie, dass, wenn Sie einen neuen Replikator mit der Startposition „Frühester Zeitpunkt für Failback“ erstellen, dieser damit beginnt, alle Daten in den Themen Ihres sekundären Clusters zu lesen. Abhängig von Ihren Datenaufbewahrungseinstellungen können Ihre Themen Daten enthalten, die aus Ihrem Quellcluster stammen. MSK Replicator filtert diese Nachrichten zwar automatisch, es fallen jedoch weiterhin Datenverarbeitungs- und Übertragungsgebühren für alle Daten in Ihrem sekundären Cluster an. Sie können die gesamten vom Replicator verarbeiteten Daten mithilfe von verfolgen. ReplicatorBytesInPerSec

Prefixed topic name replication

Sie sollten Failback-Schritte erst einleiten, wenn die Replikation vom Cluster in der sekundären Region zum Cluster in der primären Region aufgeholt hat und die MessageLag Metrik in Amazon nahe 0 CloudWatch liegt. Ein geplantes Failback sollte nicht zu Datenverlust führen.

  1. Fahren Sie alle Produzenten und Verbraucher herunter, die in der sekundären Region eine Verbindung zum MSK-Cluster herstellen.

  2. Löschen Sie bei einer aktiv-passiven Topologie den Replikator, der Daten aus dem Cluster in der sekundären Region in die primäre Region repliziert. Sie müssen den Replikator für eine Aktiv-Aktiv-Topologie nicht löschen.

  3. Starten Sie Produzenten, die eine Verbindung zum MSK-Cluster in der primären Region herstellen.

  4. Wenn Ihre Anwendung keine Nachrichtenreihenfolge erfordert, starten Sie Benutzer in der primären AWS Region, die mithilfe eines Platzhalteroperators sowohl aus den lokalen als auch aus den replizierten Themen lesen. Wenn für Ihre Anwendung die Reihenfolge der Nachrichten erforderlich ist, starten Sie zunächst nur die Benutzer für die replizierten Themen, warten Sie, bis die Verzögerung 0 erreicht, und wechseln Sie dann zu lokalen Themen.

  5. Stellen Sie anhand der Metriken und Latenz sicher, dass sich der bestehende Replikator vom Cluster in der primären Region zum Cluster in der sekundären Region im Status RUNNING befindet ReplicatorThroughput und erwartungsgemäß funktioniert.