Кафка долгое время загрузки координатора и маленькие ISR

Question

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

Неизвестное событие привело к переходу кластера в состояние "загрузка координатора" или "групповая загрузка". Несколько сигналов сделали это очевидным: потребители на основе пикафки начали терпеть неудачу во время 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 - неясно, почему Kafka выбрал несинхронизированную реплику в качестве предпочтительного лидера.

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

Вопросы

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