☰

Lange Ladezeit des Kafka-Koordinators und kleine ISRs

tag-icon • tag-icon kafka
Lange Ladezeit des Kafka-Koordinators und kleine ISRs

Ich verwende Kafka 0.8.2.1, führe ein Thema mit 200 Partitionen und RF=3 aus und habe die Protokollaufbewahrung auf etwa 1 GB eingestellt.

Ein unbekanntes Ereignis führte dazu, dass der Cluster in den Zustand „Koordinator laden“ oder „Gruppe laden“ wechselte. Einige Signale machten dies deutlich: Die auf Pykafka basierenden Verbraucher begannen während FetchOffsetRequests mit Fehlercode 14 COORDINATOR_LOAD_IN_PROGRESSfür einige Teilmengen von Partitionen auszufallen. Diese Fehler wurden beim Konsumieren mit einer Verbrauchergruppe ausgelöst, die bereits vor dem Koordinatorladen existierte. In Broker-Protokollen erschienen Meldungen wie diese:

[2018-05...] ERROR Controller 17 epoch 20 initiated state change for partition [my.cool.topic,144] from OnlinePartition to OnlinePartition failed (state.change.logger)
kafka.common.StateChangeFailedException: encountered error while electing leader for partition [my.cool.topic,144] due to: Preferred replica 11 for partition [my.cool.topic,144] is either not alive or not in the isr. Current leader and ISR: [{"leader":12,"leader_epoch":7,"isr":[12,13]}].

Aus irgendeinem Grund entschied Kafka, dass Replik 11 die „bevorzugte“ Replik sei, obwohl sie nicht im ISR war. Meines Wissens konnte die Nutzung von Replik 12 oder 13 ohne Unterbrechung fortgesetzt werden, während 11 neu synchronisiert wurde – es ist nicht klar, warum Kafka eine nicht synchronisierte Replik als bevorzugten Leader wählte.

Das oben beschriebene Verhalten dauerte etwa 6 Stunden, während der der pykafka fetch_offsets-Fehler den Nachrichtenkonsum unmöglich machte. Während der Koordinator noch geladen wurde, konnten andere Verbrauchergruppen das Thema ohne Fehler konsumieren. Tatsächlich bestand die endgültige Lösung darin, die defekten Verbraucher mit einem neuen Namen für die Verbrauchergruppe neu zu starten.

Fragen

  1. Ist es normal oder zu erwarten, dass der Ladezustand des Koordinators 6 Stunden anhält? Wird diese Ladezeit durch die Einstellungen zur Protokollaufbewahrung, die Nachrichtenproduktionsrate oder andere Parameter beeinflusst?
  2. Nutzen Nicht-Pykafka-Clients COORDINATOR_LOAD_IN_PROGRESSnur die Partitionen, die keine Fehler aufweisen? Pykafkas Beharren darauf, dass alle Partitionen erfolgreiche OffsetFetchResponses zurückgeben, kann zu Ausfallzeiten bei der Nutzung führen.
  3. Warum wählt Kafka beim Laden des Koordinators manchmal ein nicht synchronisiertes Replikat als bevorzugtes Replikat aus? Wie kann ich Partitionsführer im ISR Replikaten neu zuweisen?
  4. Sind alle diese Fragen hinfällig, weil ich einfach eine neuere Version von Kafka verwenden sollte?

Broker-Konfigurationsoptionen:

broker.id=10
port=9092
zookeeper.connect=****/kafka5

log.dirs=*****
delete.topic.enable=true
replica.fetch.max.bytes=1048576
replica.fetch.wait.max.ms=500
replica.high.watermark.checkpoint.interval.ms=5000
replica.socket.timeout.ms=30000
replica.socket.receive.buffer.bytes=65536
replica.lag.time.max.ms=10000
replica.lag.max.messages=4000
controller.socket.timeout.ms=30000
message.max.bytes=1000000
auto.create.topics.enable=false
log.index.interval.bytes=4096
log.index.size.max.bytes=10485760
log.retention.hours=96
log.roll.hours=168
log.retention.check.interval.ms=300000
log.segment.bytes=1073741824
zookeeper.connection.timeout.ms=6000
zookeeper.sync.time.ms=2000
num.io.threads=8
socket.request.max.bytes=104857600
num.replica.fetchers=4
controller.message.queue.size=10
num.partitions=8
log.flush.interval.ms=60000
log.flush.interval.messages=60000
log.flush.scheduler.interval.ms=2000
num.network.threads=8
socket.receive.buffer.bytes=1048576
socket.send.buffer.bytes=1048576
queued.max.requests=500
fetch.purgatory.purge.interval.requests=100
producer.purgatory.purge.interval.requests=100
controlled.shutdown.enable=true

Antwort1

Ich habe nicht genau diese Kafka-Version verwendet, aber ich werde versuchen, die Fragen zu beantworten:

  1. Möglicherweise haben Sie eine unsaubere Leader-Wahl aktiviert. Dies hängt von der Anzahl der Partitionen im Vergleich zur Anzahl der Verbraucher ab.
  2. Das kann es, aber normalerweise ist Informationsintegrität wichtiger als die Betriebszeit in den meisten MQ-Systemen, wobei Kafka das sorgenfreieste ist.
  3. Unsaubere Anführerwahl auf „false“ setzen
  4. Ich weiß nicht, einige der Konzepte sind gleich geblieben.

verwandte Informationen