Kafka longo tempo de carga do coordenador e pequenos ISRs

Question

Estou usando o Kafka 0.8.2.1, executando um tópico com 200 partições e RF = 3, com a retenção de log definida para cerca de 1 GB.

Um evento desconhecido fez com que o cluster entrasse no estado "carga do coordenador" ou "carga do grupo". Alguns sinais tornaram isso aparente: os consumidores baseados em pykafka começaram a falhar durante FetchOffsetRequest s com código de erro 14 COORDINATOR_LOAD_IN_PROGRESS para algum subconjunto de partições. Esses erros foram acionados ao consumir com um grupo de consumidores que existia desde antes da carga do coordenador. Nos registros do broker, mensagens como essa apareciam:

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

Por alguma razão, Kafka decidiu que a réplica 11 era a réplica "preferida" apesar do fato de não estar no ISR. Que eu saiba, o consumo pode continuar ininterrupto a partir da réplica 12 ou 13, enquanto 11 ressincronizado - não está claro por que a Kafka escolheu uma réplica não-sincronizada como líder preferencial.

O comportamento descrito acima durou cerca de 6 horas, durante as quais o erro pykafka fetch_offsets tornou o consumo de mensagens impossível. Enquanto a carga do coordenador ainda estava em andamento, outros grupos de consumidores puderam consumir o tópico sem erros. Na verdade, a correção final era reiniciar os consumidores quebrados com um novo nome de grupo de consumidores.

Perguntas

1. É normal ou esperado que o estado de carga do coordenador dure por 6 horas? Esse tempo de carregamento é afetado pelas configurações de retenção de log, pela taxa de produção de mensagens ou por outros parâmetros?
2. Os clientes não pykafka manipulam COORDINATOR_LOAD_IN_PROGRESS consumindo apenas das partições sem erros? A insistência de Pykafka de que todas as partições retornem com êxito OffsetFetchResponse s pode ser uma fonte de tempo de inatividade de consumo.
3. Por que o Kafka às vezes seleciona uma réplica não sincronizada como a réplica preferida durante as cargas do coordenador? Como posso reatribuir os líderes de partição a réplicas no ISR?
4. Todas essas questões são discutíveis porque eu deveria estar usando uma versão mais nova do Kafka?

Opções de configuração do broker:

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

    

Answer 1

Eu não usei essa versão exata do Kafka, mas tentarei responder às perguntas:

1. Você pode ter a eleição de líder impuro ativada, depende do número de partições em relação ao número de consumidores
2. Pode, mas geralmente a integridade da informação é mais importante que o tempo de atividade na maioria dos sistemas MQ, sendo o Kafka o mais livre de problemas
3. Defina a eleição do líder não-claro como falsa
4. Eu não sei, alguns dos conceitos permaneceram os mesmos.