☰

Kafka долгое время загрузки координатора и небольшие ISR

tag-icon • tag-icon kafka
Kafka долгое время загрузки координатора и небольшие ISR

Я использую Kafka 0.8.2.1, запускаю тему с 200 разделами и RF=3, при этом размер сохранения журнала установлен примерно на 1 ГБ.

Неизвестное событие привело к тому, что кластер перешел в состояние «загрузки координатора» или «загрузки группы». Несколько сигналов сделали это очевидным: потребители на основе pykafka начали выходить из строя в течение FetchOffsetRequests с кодом ошибки 14 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]}].

По какой-то причине Кафка решил, что реплика 11 была «предпочтительной» репликой, несмотря на то, что она не была в ISR. Насколько мне известно, потребление могло продолжаться непрерывно с любой реплики 12 или 13, пока 11 ресинхронизировалась — неясно, почему Кафка выбрал несинхронизированную реплику в качестве предпочтительного лидера.

Описанное выше поведение длилось около 6 часов, в течение которых ошибка pykafka fetch_offsets сделала потребление сообщений невозможным. Пока загрузка координатора все еще продолжалась, другие группы потребителей могли потреблять тему без ошибок. Фактически, окончательное исправление заключалось в перезапуске сломанных потребителей с новым именем consumer_group.

Вопросы

  1. Нормально или ожидаемо, что состояние загрузки координатора длится 6 часов? Влияют ли на это время загрузки настройки хранения журнала, скорость создания сообщений или другие параметры?
  2. Обрабатывают ли клиенты, не являющиеся pykafka, COORDINATOR_LOAD_IN_PROGRESSпотребление только из разделов, не имеющих ошибок? Настойчивое требование Pykafka о том, чтобы все разделы возвращали успешные OffsetFetchResponses, может быть источником простоя потребления.
  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

Я не использовал именно эту версию Кафки, но постараюсь ответить на вопросы:

  1. У вас могут быть включены некорректные выборы лидера, это зависит от количества разделов и количества потребителей.
  2. Это возможно, но обычно целостность информации важнее времени безотказной работы в большинстве систем MQ, а Kafka — самая простая в использовании.
  3. Установить нечистые выборы лидера на ложь
  4. Не знаю, некоторые концепции остались прежними.

Связанный контент