Führen Sie ein Failback zur primären Region durch AWS - 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.

Führen Sie ein Failback zur primären Region durch AWS

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

Gehen Sie wie folgt vor, wenn Sie die Konfiguration für die Replikation identischer Themennamen verwenden:

  1. Erstellen Sie einen neuen MSK Replicator mit Ihrem sekundären Cluster als Quell- und primärem Cluster als Ziel, wobei die Startposition auf die früheste und die Replikation identischer Themennamen gesetzt ist (behalten Sie denselben Themennamen in der Konsole bei).

    Dadurch wird der Vorgang gestartet, bei dem alle Daten, die nach dem Failover in den sekundären Cluster geschrieben wurden, zurück in die primäre Region kopiert werden.

  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“ und in Amazon CloudWatch 0 die ReplicatorThroughput Metrik hat.

    Beachten Sie, dass, wenn Sie einen neuen Replikator mit der Startposition „Frühestens für Failback“ erstellen, dieser damit beginnt, alle Daten in den Themen Ihrer sekundären Cluster 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 Siehe MSK-Replikatormetriken.

Wenn Sie die Konfiguration für Themennamen mit Präfix verwenden, gehen Sie wie folgt vor:

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-Passiv-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. Befolgen Sie die Schritte auf einer der folgenden Registerkarten, je nachdem, welche Anforderungen Ihre Anwendung für die Nachrichtenreihenfolge hat.

    No message ordering

    Wenn für Ihre Anwendung keine Nachrichtenreihenfolge erforderlich ist, starten Sie Benutzer in der primären AWS Region, die sowohl aus den lokalen (z. B.topic) als auch aus den replizierten Themen (z. B.<sourceKafkaClusterAlias>.topic) lesen, indem Sie einen Platzhalteroperator (z. B.) verwenden. .*topic Die Verbraucher, die sich mit lokalen Themen (z. B. Thema) befassen, beginnen ab dem letzten Offset, das sie vor dem Failover konsumiert haben. Wenn vor dem Failover unverarbeitete Daten vorhanden waren, werden diese jetzt verarbeitet. Im Falle eines geplanten Failovers sollte es keinen solchen Datensatz geben.

    Message ordering
    1. Starten Sie Verbraucher nur für die replizierten Themen in der primären Region (z. B. <sourceKafkaClusterAlias>.topic), aber nicht für die lokalen Themen (z. B. topic).

    2. Warten Sie, bis alle Verbraucher replizierter Themen auf dem Cluster in der primären Region die Verarbeitung aller Daten abgeschlossen haben, sodass die Offset-Verzögerung 0 und die Anzahl der verarbeiteten Datensätze ebenfalls 0 ist. Stoppen Sie dann die Verbraucher für die replizierten Themen auf dem Cluster in der primären Region. Zu diesem Zeitpunkt wurden alle Datensätze, die nach dem Failover in der sekundären Region erstellt wurden, in der primären Region verbraucht.

    3. Starten Sie Verbraucher für die lokalen Themen (z. B. topic) auf dem Cluster in der primären Region.

  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 und erwartungsgemäß funktioniert. ReplicatorThroughput