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.
Offset-Synchronisierung für Nutzergruppen
MSK Replicator kann Offsets von Nutzergruppen von einem Quellcluster zu einem Zielcluster synchronisieren, sodass Benutzer zwischen Clustern wechseln und die Verarbeitung fortsetzen können, ohne Datensätze zu überspringen. In diesem Thema wird beschrieben, wie die Offset-Synchronisierung sowohl in unidirektionalen (Legacy) als auch in bidirektionalen (erweiterten) Konfigurationen funktioniert, und es werden häufig auftretende Fallstricke aufgezeigt.
Wie funktioniert die Offset-Synchronisierung
Im Rahmen der Datenreplikation verarbeitet MSK Replicator Nachrichten aus dem Quellcluster und sendet sie an den Zielcluster. Dies kann dazu führen, dass Nachrichten auf Ihren Quell- und Zielclustern unterschiedliche Offsets aufweisen. Wenn Sie bei der Erstellung des Replikators die Offset-Synchronisierung für Nutzergruppen aktiviert haben, übersetzt MSK Replicator beim Kopieren der Metadaten automatisch die Offsets, sodass Ihre Benutzer nach einem Failover zum Zielcluster die Verarbeitung dort fortsetzen können, wo sie aufgehört haben.
MSK Replicator optimiert für Nutzer auf dem Quell-Cluster, die von einer Position aus lesen, die näher am Ende des Streams liegt (Ende der Themenpartition). Wenn Ihre Nutzergruppen im Quell-Cluster hinterherhinken, können Sie bei diesen Nutzergruppen auf dem Ziel-Cluster eine höhere Verzögerung feststellen als bei der Quelle, was bedeutet, dass Verbraucher nach einem Failover mehr doppelte Nachrichten erneut verarbeiten werden. Um diese Verzögerung zu verringern, müssen Ihre Verbraucher auf dem Quell-Cluster aufholen und von der Spitze des Streams aus mit dem Konsum beginnen. Wenn Ihre Kunden aufholen, reduziert MSK Replicator die Verzögerung automatisch.
Die Offset-Synchronisierung ist eine dreistufige Pipeline:
Offset-Mapping — Während Datensätze von der Quelle zum Ziel repliziert werden, zeichnet der Replikator periodische Zuordnungen zwischen Quell-Offsets und den entsprechenden Ziel-Offsets auf. Da Quell- und Zielversätze voneinander abweichen (unterschiedliche Startpunkte, Verdichtung usw.), sind diese Zuordnungen unerlässlich.
Offset-Übersetzung — In regelmäßigen Abständen liest der Replikator die festgeschriebenen Offsets für jede replizierte Nutzergruppe auf dem Quell-Cluster. Anschließend verwendet er die gespeicherten Offset-Zuordnungen, um diese Quell-Offsets in die entsprechenden Ziel-Offsets umzurechnen.
Offset-Commit — Die übersetzten Offsets werden dem
__consumer_offsetsThema des Ziel-Clusters zugewiesen. Wenn also ein Nutzer eine Verbindung zum Ziel-Cluster herstellt und derselben Gruppe beitritt, nimmt er die Arbeit von ungefähr der richtigen Position aus wieder auf.
Wichtigste Verhaltensweisen:
Die Offset-Übersetzung ist ungefähr, nicht exakt. Der Replikator tastet die Offset-Mappings in Intervallen ab, sodass der umgerechnete Offset etwas hinter der tatsächlichen Entsprechungsposition liegen kann. Das liegt in der Natur der Technik — es handelt sich um einen Fehler bei der at-least-once Zustellung, was bedeutet, dass Verbraucher nach einem Failover eine kleine Anzahl von Nachrichten erneut lesen können.
Offsets gelten nur dann für eine Verbrauchergruppe auf der Zielseite, wenn in dieser Zielgruppe kein Verbraucher aktiv konsumiert. Dadurch wird verhindert, dass der Replikator Verbraucher stört, die bereits auf dem Zielcluster ausgeführt werden.
Nutzergruppen müssen dem konfigurierten Nutzergruppenfilter (Ein-/Ausschlussmuster) entsprechen, damit sie synchronisiert werden können.
Unidirektionale Replikation mit älterer Offset-Synchronisierung
Dies ist der Standardmodus für einen unidirektionalen Standardreplikator (Cluster A → Cluster B).
Themenbenennung — Legacy-Offset-Synchronisierung unterstützt sowohl die Replikation mit Präfixen als auch mit identischen Themennamen.
Richtung — Offsets für Verbrauchergruppen werden nur dann mit dem Zielcluster synchronisiert, wenn Produzenten auf dem Quellcluster aktiv und Verbraucher auf dem Zielcluster inaktiv sind.
Failover — Verbraucher können auf den Zielcluster verwiesen werden und können dann von der übersetzten Offset-Position aus weitermachen.
Keine Failback-Unterstützung — Bei der Legacy-Offset-Synchronisierung werden Offsets vom Ziel nicht zurück in die Quelle übersetzt. Wenn Sie Kunden an die Zieladresse weiterleiten und sie später wieder an die Quelle weiterleiten möchten, gibt es keine automatische Offset-Übersetzung für die Rückreise. Wenn ein Failback erforderlich ist, verwenden Sie ein bidirektionales Setup mit verbesserter Offset-Synchronisierung.
Bidirektionales Setup mit verbesserter Offset-Synchronisierung
Eine bidirektionale Konfiguration erfordert zwei Replikatoren, die in entgegengesetzte Richtungen laufen (Replicator A→B und Replicator B→A). Jeder Replikator führt weiterhin unidirektionale Datenreplikation und Offset-Synchronisierung durch — er repliziert Daten von der Quelle zum Ziel und synchronisiert die Offsets der Nutzergruppen in dieselbe Richtung. Durch die verbesserte Offset-Synchronisierung ist jeder Replikator in der Lage, Nutzergruppen auch dann weiter zu synchronisieren, wenn Produzenten und Verbraucher auf unterschiedlichen Clustern aktiv sind.
Wichtigste Merkmale:
Themenbenennung — Die erweiterte Synchronisierung erfordert die identische Replikation von Themennamen auf beiden Replikatoren.
Zwei Replikatoren, jeder unidirektional — Jeder Replikator repliziert Daten und synchronisiert Offsets in eine Richtung. Das bidirektionale Verhalten ist darauf zurückzuführen, dass das Paar zusammenarbeitet.
Liest Mappings von beiden Replikatoren — Bei der Übersetzung von Offsets arbeiten die Replikatoren zusammen, um die genaueste verfügbare Übersetzung zu ermitteln.
Failover und Failback — Verbraucher können von einem Cluster zum anderen verschoben werden und dann von ungefähr der richtigen Position wieder aufgenommen werden.
Wann sollte die bidirektionale Offset-Synchronisierung aktiviert werden:
Migration mit Rollback-Fähigkeit — Wenn Sie von einem Cluster zu einem anderen migrieren und Sie die Möglichkeit haben möchten, bei Problemen zum ursprünglichen Cluster zurückzukehren.
Active-Active-Architekturen — Wenn beide Cluster aktiv Lese- und Schreibvorgänge ausführen und Sie benötigen, dass Verbraucher zwischen Clustern wechseln können.
Disaster Recovery — Wenn Sie sicherstellen müssen, dass Verbraucher die Verarbeitung nach einem Failover- oder Failback-Ereignis vom richtigen Offset auf einem der Cluster wieder aufnehmen können.
Überwachung der Offset-Synchronisierung
Überwachen Sie die folgenden CloudWatch Amazon-Metriken, um sicherzustellen, dass die Offset-Synchronisierung ordnungsgemäß funktioniert:
ConsumerGroupCount— Stellen Sie sicher, dass die erwartete Anzahl von Nutzergruppen auf beiden Replikatoren synchronisiert wird.ConsumerGroupOffsetSyncFailure— Sollte auf beiden Replikatoren 0 sein. Wenn dieser Wert größer als 0 ist, überprüfen Sie, ob die Nutzergruppen aktiv sind, überprüfen Sie die Berechtigungen Lesen und Beschreiben und stellen Sie sicher, dass Themen auf dem Zielcluster vorhanden sind.OffsetLag (MSK Cluster)undOffsetLag (Non-MSK Cluster)— Vergleichen Sie die Consumer-Verzögerung auf Partitionsebene in beiden Clustern, um sicherzustellen, dass die Offsets synchronisiert sind.
Häufige Fallstricke
-
Verbraucher können nach einem Failover eine kleine Anzahl von Nachrichten erneut lesen
Die Offset-Übersetzung ist eine ungefähre Angabe Der umgerechnete Offset ist bewusst konservativ — er kann leicht hinter der tatsächlichen Entsprechungsposition zurückbleiben. Das bedeutet, dass Verbraucher nach einem Clusterwechsel in der Regel eine kleine Anzahl von Datensätzen erneut verarbeiten. Anwendungen sollten so konzipiert sein, dass sie doppelte Verarbeitung (Idempotenz) verarbeiten können.
-
Offsets werden nicht mit Gruppen synchronisiert, die das Ziel aktiv nutzen
Wenn eine Nutzergruppe auf dem Zielcluster bereits aktiv ist, überschreibt der Replikator ihre Offsets nicht. Dies ist ein Sicherheitsmechanismus. Das bedeutet jedoch, dass, wenn Verbraucher auf dem Ziel gestartet werden, bevor der Replikator die Möglichkeit hatte, die Offsets zu synchronisieren, diese Verbraucher mit der Standard-Offset-Reset-Richtlinie des Ziels beginnen (typischerweise
latestoderearliest), nicht mit der übersetzten Position. -
Die Offset-Synchronisierung hat eine inhärente Verzögerung
Die Offset-Übersetzung hängt von zwei asynchronen Prozessen ab: der Datenreplikation und der Offset-Synchronisierung. Es gibt immer eine gewisse Verzögerung zwischen dem Zeitpunkt, an dem ein Verbraucher einen Offset an der Quelle festlegt, und dem Zeitpunkt, an dem der übersetzte Offset auf dem Ziel erscheint. Während eines Failovers kann diese Verzögerung dazu führen, dass Verbraucher mehr Nachrichten erneut lesen als erwartet, wenn der ursprüngliche Verbraucher erst vor Kurzem aktiv war.
-
Nutzergruppen müssen im Replikationsfilter enthalten sein
Nur bei Nutzergruppen, die dem konfigurierten Include-Muster (und nicht dem Exclude-Muster) entsprechen, werden ihre Offsets synchronisiert. Wenn die Offsets einer Nutzungsgruppe nicht auf dem Ziel erscheinen, stellen Sie sicher, dass sie in der Konfiguration für die Replikation der Nutzungsgruppe enthalten sind.
-
Unidirektionale Replikatoren unterstützen kein Failback
Bei der herkömmlichen (unidirektionalen) Offset-Synchronisierung werden Offsets nur von der Quelle zum Ziel übersetzt. Wenn Sie Verbraucher zum Ziel weiterleiten und sie später wieder zur Quelle verschieben müssen, müssen Sie die korrekten Offsets manuell ermitteln oder eine erneute Verarbeitung akzeptieren. Wenn ein Failback erforderlich ist, verwenden Sie ein bidirektionales Setup mit verbesserter Offset-Synchronisierung.
-
Durch Löschen und Neuerstellen von Themen können Offset-Mappings ungültig werden
Wenn ein Thema gelöscht und in einem der Cluster neu erstellt wird, veralten die Offset-Mappings, weil das neue Thema bei Offset 0 beginnt. Bei der älteren Offset-Synchronisierung kann dies zu falschen Offset-Übersetzungen führen. Die verbesserte Offset-Synchronisierung erkennt die Neuformierung von Themen und setzt die Zuordnungen automatisch zurück.
