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

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

Из-за неизвестного события кластер перешел в состояние «загрузка координатора» или «групповая загрузка». Это стало очевидным по нескольким сигналам: потребители на пикафке начали отказывать во время 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