我使用的是kafka0.8.2.1，运行的主题有200个分区，rf=3，日志保留设置为1gb左右。
未知事件导致群集进入“协调器加载”或“组加载”状态。有几个信号表明了这一点：以皮Kafka为基础的消费者在这一时期开始失败 FetchOffsetRequest s，错误代码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]}].

出于某种原因，Kafka决定复制品11是“首选”复制品，尽管它不在isr中。据我所知，当11个副本重新同步时，消耗可以从副本12或13不间断地继续下去——不清楚Kafka为什么选择不同步的副本作为首选的领导者。
上述行为持续了大约6个小时，在此期间，pykafka fetch\u offsets错误导致无法使用消息。当协调器加载仍在进行时，其他使用者组能够正确地使用该主题。事实上，最终的解决办法是用一个新的消费组名称重新启动损坏的消费者。
问题
协调器负载状态持续6小时是正常的还是预期的？此加载时间是否受日志保留设置、邮件生成速率或其他参数的影响？
非pykafka客户端是否处理 COORDINATOR_LOAD_IN_PROGRESS 只消耗非出错分区的数据？pykafka坚持所有分区都返回成功 OffsetFetchResponse s可能是消耗停机时间的来源。
为什么Kafka有时会在协调器加载期间选择一个非同步副本作为首选副本？如何将分区引线重新分配给isr中的副本？
所有这些问题都没有意义是因为我应该使用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