View a markdown version of this page

Broker offline und Client-Failover - 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.

Broker offline und Client-Failover

Kafka ermöglicht einen Offline-Broker; ein einzelner Offline-Broker in einem gesunden und ausgewogenen Cluster, der sich an bewährte Verfahren hält, wird keine Auswirkungen haben oder zu Produktions- oder Konsumausfällen führen. Dies liegt daran, dass ein anderer Broker die Partitionsleitung übernimmt und dass die Kafka-Client-Lib automatisch einen Failover durchführt und Anfragen an die neuen Leader-Broker sendet.

Client-Server-Vertrag

Dies führt zu einem gemeinsamen Vertrag zwischen der Client-Bibliothek und dem serverseitigen Verhalten. Der Server muss erfolgreich einen oder mehrere neue Leiter zuweisen und der Client muss den Broker wechseln, um Anfragen an die neuen Leiter rechtzeitig zu senden.

Kafka verwendet Ausnahmen, um diesen Ablauf zu steuern:

Ein Beispielverfahren

  1. Broker A wechselt in einen Offline-Status.

  2. Der Kafka-Client erhält eine Ausnahme (normalerweise eine Netzwerkunterbrechung oder not_leader_for_partition).

  3. Diese Ausnahmen veranlassen den Kafka-Client, seine Metadaten zu aktualisieren, sodass er über die neuesten Marktführer informiert ist.

  4. Der Kafka-Client setzt das Senden von Anfragen an die neuen Partitionsleiter anderer Broker fort.

Dieser Vorgang dauert mit dem verkauften Java-Client und den Standardkonfigurationen in der Regel weniger als 2 Sekunden. Die clientseitigen Fehler sind ausführlich und wiederholen sich, geben jedoch keinen Anlass zur Sorge, was durch die Stufe „WARN“ gekennzeichnet ist.

Beispiel: Ausnahme 1

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2

Beispiel: Ausnahme 2

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"

Kafka-Clients beheben diese Fehler automatisch in der Regel innerhalb von 1 Sekunde und höchstens 3 Sekunden. Bei den clientseitigen Messwerten entspricht dies einer produce/consume Latenz von p99 (normalerweise hohe Millisekunden im Bereich von 100). Länger als dieser Wert deutet in der Regel auf ein Problem mit der Client-Konfiguration oder der serverseitigen Controller-Auslastung hin. Bitte lesen Sie den Abschnitt zur Problembehandlung.

Ein erfolgreicher Failover kann überprüft werden, indem Sie überprüfen, ob die BytesInPerSec LeaderCount Kennzahlen bei anderen Brokern steigen. Dies beweist, dass sich der Traffic und die Führung erwartungsgemäß entwickelt haben. Sie werden auch einen Anstieg der UnderReplicatedPartitions Metrik beobachten, was zu erwarten ist, wenn Replikate mit dem Shutdown-Broker offline sind.

Fehlerbehebung

Der oben genannte Ablauf kann unterbrochen werden, wenn der Client-Server-Vertrag gebrochen wird. Zu den häufigsten Gründen für das Problem gehören:

  • Fehlkonfiguration oder falsche Verwendung der Kafka-Client-Bibliotheken.

  • Unerwartetes Standardverhalten und Fehler bei Client-Bibliotheken von Drittanbietern.

  • Überlasteter Controller, was zu einer langsameren Zuweisung des Partitionsleiters führt.

  • Es wird ein neuer Controller gewählt, was zu einer langsameren Zuweisung des Partitionsleiters führt.

Um ein korrektes Verhalten beim Umgang mit einem Failover der Unternehmensleitung sicherzustellen, empfehlen wir:

  • Es müssen serverseitige Best Practices befolgt werden, um sicherzustellen, dass der Controller-Broker angemessen skaliert wird, um eine langsame Zuweisung von Führungskräften zu vermeiden.

  • In den Clientbibliotheken müssen Wiederholungsversuche aktiviert sein, um sicherzustellen, dass der Client das Failover handhabt.

  • In den Clientbibliotheken muss retry.backoff.ms konfiguriert sein (Standardeinstellung 100), um Stürme zu vermeiden. connection/request

  • Die Clientbibliotheken müssen request.timeout.ms und delivery.timeout.ms auf Werte setzen, die der SLA der Anwendungen entsprechen. Höhere Werte führen bei bestimmten Fehlertypen zu einem langsameren Failover.

  • Clientbibliotheken müssen sicherstellen, dass bootstrap.servers mindestens 3 zufällige Broker enthält, um zu verhindern, dass die Verfügbarkeit bei der ersten Erkennung beeinträchtigt wird.

  • Einige Clientbibliotheken sind niedriger als andere und erwarten, dass der Anwendungsentwickler die Wiederholungslogik und die Ausnahmebehandlung selbst implementiert. Informationen zur Verwendung finden Sie in der spezifischen Dokumentation für die Clientbibliothek und stellen Sie sicher, dass die richtige reconnect/retry Logik befolgt wird.

  • Wir empfehlen, die clientseitige Latenz für Produkte, die Anzahl erfolgreicher Anfragen und die Anzahl der Fehler bei nicht wiederholbaren Fehlern zu überwachen.

  • Wir haben beobachtet, dass ältere Golang- und Ruby-Bibliotheken von Drittanbietern während eines gesamten Offline-Zeitraums des Brokers immer noch ausführlich sind, obwohl Producing- und Consum-Anfragen davon nicht betroffen sind. Wir empfehlen Ihnen, neben den Erfolgs- und Fehlerzahlen Ihrer Anfragen stets die Kennzahlen auf Unternehmensebene im Auge zu behalten, um festzustellen, ob Ihre Protokolle tatsächlich Auswirkungen oder Störungen aufweisen.

  • Kunden sollten sich keine Sorgen über vorübergehende Ausnahmen machen, network/not_leader da sie normal sind, keine Auswirkungen haben und im Rahmen des Kafka-Protokolls erwartet werden.

  • Kunden sollten sich keine Sorgen machen, UnderReplicatedPartitions da sie normal sind, keine Auswirkungen haben und von einem einzigen Offline-Broker erwartet werden.