☰

Longo tempo de carregamento do coordenador Kafka e pequenos ISRs

tag-icon • tag-icon kafka
Longo tempo de carregamento do coordenador Kafka e pequenos ISRs

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

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 FetchOffsetRequests com código de erro 14 COORDINATOR_LOAD_IN_PROGRESSpara algum subconjunto de partições. Esses erros foram acionados ao consumir com um grupo de consumidores que existia antes da carga do coordenador. Nos logs do corretor, mensagens como esta apareceram:

[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 de não estar no ISR. Que eu saiba, o consumo poderia continuar ininterrupto a partir da réplica 12 ou 13, enquanto a 11 era ressincronizada - não está claro por que 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 impossibilitou o consumo de mensagens. Enquanto a carga do coordenador ainda estava em andamento, outros grupos de consumidores conseguiram consumir o tópico sem erros. Na verdade, a solução final foi reiniciar os consumidores quebrados com um novo nome de consumer_group.

Questões

  1. É normal ou esperado que o estado de carga do coordenador dure 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 consomem COORDINATOR_LOAD_IN_PROGRESSapenas das partições sem erros? A insistência de Pykafka para que todas as partições retornem OffsetFetchResponses bem-sucedidas pode ser uma fonte de tempo de inatividade do consumo.
  3. Por que o Kafka às vezes seleciona uma réplica não sincronizada como a réplica preferida durante os carregamentos do coordenador? Como posso reatribuir líderes de partição a réplicas no ISR?
  4. Todas essas questões são discutíveis porque eu deveria usar apenas uma versão mais recente do Kafka?

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

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

Responder1

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 versus o 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 Kafka o mais despreocupado
  3. Definir eleição de líder impuro como falsa
  4. Não sei, alguns dos conceitos permaneceram os mesmos.

informação relacionada