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.
Zu einem MSK Amazon-Cluster migrieren
Amazon MSK Replicator kann für die MSK Cluster-Migration verwendet werden. Siehe Was ist Amazon MSK Replicator?. Alternativ können Sie Apache MirrorMaker 2.0 verwenden, um von einem MSK Nicht-Cluster zu einem MSK Amazon-Cluster zu migrieren. Ein Beispiel dafür finden Sie unter Migrieren eines lokalen Apache Kafka-Clusters zu Amazon mithilfe MSK von. MirrorMaker Informationen zur Verwendung MirrorMaker finden Sie unter Spiegeln von Daten zwischen Clustern
Eine Übersicht der Schritte, die bei der Migration MirrorMaker zu einem MSK Cluster zu befolgen sind
Erstellen Sie den MSK Zielcluster
Starten Sie MirrorMaker von einer EC2 Amazon-Instance innerhalb desselben Amazon-Clusters VPC wie der Zielcluster.
-
Untersuchen Sie die MirrorMaker Verzögerung.
-
Leiten MirrorMaker Sie nach dem Aufholen die Produzenten und Verbraucher mithilfe der Cluster-Bootstrap-Broker auf den neuen MSK Cluster um.
-
Herunterfahren. MirrorMaker
MirrorMaker 1.0 bewährte Methoden
Diese Liste mit bewährten Methoden gilt für MirrorMaker 1.0.
MirrorMaker Auf dem Zielcluster ausführen. Wenn ein Netzwerkproblem auftritt, sind die Nachrichten auf diese Weise weiterhin im Quell-Cluster verfügbar. Wenn Sie MirrorMaker auf dem Quellcluster ausführen und Ereignisse im Producer zwischengespeichert werden und es ein Netzwerkproblem gibt, gehen Ereignisse möglicherweise verloren.
-
Wenn während der Übertragung eine Verschlüsselung erforderlich ist, führen Sie diese im Quell-Cluster aus.
Legen Sie für Konsumenten „auto.commit.enabled=false“ fest.
Für Produzenten legen Sie Folgendes fest:
max.in.flight.requests.per.connection=1
retries=Int.Max_Value
acks=all
max.block.ms = Long.Max_Value
Für einen hohen Produzentendurchsatz:
Nachrichten puffern und Nachrichten-Batches füllen – buffer.memory, batch.size, linger.ms optimieren
Socket-Puffer optimieren – receive.buffer.bytes, send.buffer.bytes
Um Datenverlust zu vermeiden, schalten Sie das auto Commit an der Quelle aus, sodass die Commits gesteuert werden MirrorMaker können. Dies geschieht normalerweise, nachdem es das ACK vom Zielcluster erhalten hat. Wenn der Producer acks=all und der Zielcluster min.insync.replicas auf mehr als 1 gesetzt hat, werden die Nachrichten auf mehr als einem Broker am Ziel gespeichert, bevor der Verbraucher den Offset an der Quelle festschreibt. MirrorMaker
-
Wenn die Reihenfolge wichtig ist, können Sie die Wiederholungsversuche auf „0“ festlegen. Setzen Sie die maximalen Inflight-Verbindungen für eine Produktionsumgebung alternativ auf „1“, um sicherzustellen, dass die Commits für die versendeten Stapel in der richtigen Reihenfolge durchgeführt werden, falls ein Stapel in der Mitte ausfällt. Auf diese Weise wird jeder gesendete Stapel wiederholt, bis der nächste Stapel gesendet wird. Wenn „max.block.ms“ nicht auf den Maximalwert festgelegt ist und der Puffer des Produzenten voll ist, kann es zu Datenverlust kommen (abhängig von einigen der anderen Einstellungen). Dies kann den Konsumenten blockieren und Druck erzeugen.
-
Für hohen Durchsatz
-
Erhöhen Sie den Pufferspeicher.
-
Erhöhen Sie die Stapelgröße.
-
Passen Sie linger.ms an, damit die Stapel gefüllt werden können. Dies ermöglicht zudem eine bessere Komprimierung, weniger Auslastung der Netzwerkbandbreite und weniger Speicher auf dem Cluster. Dies führt zu einer erhöhten Retention.
-
Überwachung und Speichernutzung. CPU
-
-
Für hohen Konsumentendurchsatz
-
Erhöhen Sie die Anzahl der Threads/Verbraucher pro MirrorMaker Prozess — num.streams.
-
Erhöhen Sie zunächst die Anzahl der MirrorMaker Prozesse auf allen Computern, bevor Sie die Anzahl der Threads erhöhen, um eine hohe Verfügbarkeit zu gewährleisten.
-
Erhöhen Sie die Anzahl der MirrorMaker Prozesse zuerst auf demselben Computer und dann auf verschiedenen Computern (mit derselben Gruppen-ID).
-
Isolieren Sie Themen mit sehr hohem Durchsatz und verwenden Sie separate MirrorMaker Instanzen.
-
Für Verwaltung und Konfiguration
-
AWS CloudFormation Verwendungs- und Konfigurationsmanagement-Tools wie Chef und Ansible.
-
Verwenden Sie EFS Amazon-Mounts, damit alle Konfigurationsdateien von allen EC2 Amazon-Instances aus zugänglich sind.
-
Verwenden Sie Container für die einfache Skalierung und Verwaltung von MirrorMaker Instances.
-
In der Regel braucht es mehr als einen Verbraucher, um einen Hersteller zu überzeugen. MirrorMaker Richten Sie also mehrere Konsumenten ein. Richten Sie sie zunächst auf verschiedenen Computern ein, um eine hohe Verfügbarkeit zu gewährleisten. Skalieren Sie dann einzelne Computer bis zu einem Konsumenten pro Partition, wobei die Konsumenten gleichmäßig auf die Computer verteilt sind.
-
Da die Standardwerte möglicherweise zu niedrig sind, optimieren Sie die Puffer für Empfangen und Senden, um einen hohen Durchsatz zu erreichen. Um eine maximale Leistung zu erzielen, stellen Sie sicher, dass die Gesamtzahl der Streams (num.streams) mit allen Themenpartitionen übereinstimmt, MirrorMaker die versucht werden, in den Zielcluster zu kopieren.
Vorteile von 2. MirrorMaker *
Nutzt das Apache Kafka Connect-Framework und -Partnersystem.
Erkennt neue Themen und Partitionen.
Synchronisiert die Themenkonfiguration automatisch zwischen Clustern.
Unterstützt „aktiv/aktiv“-Clusterpaare sowie eine beliebige Anzahl aktiver Cluster.
-
Bietet neue Metriken, einschließlich der end-to-end Replikationslatenz über mehrere Rechenzentren und Cluster hinweg.
-
Gibt Offsets aus, die für die Migration von Konsumenten zwischen Clustern erforderlich sind, und stellt Werkzeuge für die Offset-Übertragung bereit.
-
Unterstützt eine Konfigurationsdatei auf hoher Ebene, mit der mehrere Cluster und Replikationsabläufe an einem zentralen Ort spezifiziert werden können, verglichen mit den Eigenschaften auf niedriger Ebene für jeden MirrorMaker 1.*-Prozess.
