☰

Kafka の長いコーディネータのロード時間と小さな ISR

tag-icon • tag-icon kafka
Kafka の長いコーディネータのロード時間と小さな ISR

私は Kafka 0.8.2.1 を使用しており、200 パーティション、RF=3、ログ保持期間を約 1 GB に設定してトピックを実行しています。

不明なイベントにより、クラスターが「コーディネーター ロード」または「グループ ロード」状態になりました。いくつかのシグナルから、このことが明らかになりました。pykafka ベースのコンシューマーは、一部のパーティションのサブセットFetchOffsetRequestでエラー コード 14 が発生し、s中に失敗し始めましたCOORDINATOR_LOAD_IN_PROGRESS。これらのエラーは、コーディネーター ロードの前から存在していたコンシューマー グループで消費しているときに発生しました。ブローカー ログには、次のようなメッセージが表示されました。

[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]}].

何らかの理由で、Kafka は、ISR にないにもかかわらず、レプリカ 11 を「優先」レプリカと決定しました。私の知る限り、レプリカ 11 が再同期されている間、レプリカ 12 または 13 のいずれかから消費を中断することなく継続できます。Kafka が同期されていないレプリカを優先リーダーとして選択した理由は明らかではありません。

上記の動作は約 6 時間続き、その間、pykafka fetch_offsets エラーによりメッセージの消費が不可能になりました。コーディネーターのロードがまだ進行中だった間、他のコンシューマー グループはエラーなしでトピックを消費できました。実際、最終的な修正は、壊れたコンシューマーを新しい consumer_group 名で再起動することでした。

質問

  1. コーディネーターの負荷状態が 6 時間続くのは正常または予想されますか? この負荷時間は、ログ保持設定、メッセージ生成率、またはその他のパラメータによって影響を受けますか?
  2. 非 pykafka クライアントは、COORDINATOR_LOAD_IN_PROGRESSエラーのないパーティションからのみ消費して処理しますか? すべてのパーティションが成功したOffsetFetchResponses を返すという pykafka の要求は、消費のダウンタイムの原因となる可能性があります。
  3. コーディネーターのロード中に、Kafka が同期されていないレプリカを優先レプリカとして選択することがあります。なぜでしょうか? ISR でパーティション リーダーをレプリカに再割り当てするにはどうすればよいですか?
  4. 新しいバージョンの Kafka を使用すればいいだけなので、これらの質問はすべて無意味でしょうか?

ブローカー設定オプション:

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

答え1

私はその正確な Kafka バージョンを使用したことはありませんが、質問に答えてみようと思います。

  1. クリーンでないリーダー選出が有効になっている可能性があります。これはパーティションの数とコンシューマーの数によって異なります。
  2. 可能ですが、ほとんどのMQシステムでは情報の整合性が稼働時間よりも重要であり、Kafkaは最も気を遣う必要がないシステムです。
  3. 不正なリーダー選出を false に設定する
  4. 分かりませんが、いくつかのコンセプトは同じままでした。

関連情報