☰

Tiempo de carga prolongado del coordinador de Kafka e ISR pequeños

tag-icon • tag-icon kafka
Tiempo de carga prolongado del coordinador de Kafka e ISR pequeños

Estoy usando Kafka 0.8.2.1, ejecutando un tema con 200 particiones y RF=3, con la retención de registros configurada en aproximadamente 1 GB.

Un evento desconocido provocó que el clúster entrara en el estado de "carga de coordinador" o "carga de grupo". Algunas señales hicieron esto evidente: los consumidores basados ​​en pykafka comenzaron a fallar durante FetchOffsetRequests con el código de error 14 COORDINATOR_LOAD_IN_PROGRESSpara algún subconjunto de particiones. Estos errores se activaron al consumir con un grupo de consumidores que existía desde antes de la carga del coordinador. En los registros del corredor, aparecieron mensajes como este:

[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 alguna razón, Kafka decidió que la réplica 11 era la réplica "preferida" a pesar de que no estaba en el ISR. Hasta donde yo sé, el consumo podría continuar ininterrumpidamente desde la réplica 12 o 13 mientras la 11 se resincroniza; no está claro por qué Kafka eligió una réplica no sincronizada como líder preferida.

El comportamiento descrito anteriormente duró aproximadamente 6 horas, durante las cuales el error pykafka fetch_offsets hizo imposible el consumo de mensajes. Mientras la carga del coordinador aún estaba en progreso, otros grupos de consumidores pudieron consumir el tema sin errores. De hecho, la solución final fue reiniciar los consumidores rotos con un nuevo nombre de grupo de consumidores.

Preguntas

  1. ¿Es normal o se espera que el estado de carga del coordinador dure 6 horas? ¿Este tiempo de carga se ve afectado por la configuración de retención de registros, la tasa de producción de mensajes u otros parámetros?
  2. ¿Los clientes que no son pykafka se manejan COORDINATOR_LOAD_IN_PROGRESSconsumiendo solo desde las particiones que no tienen errores? La insistencia de Pykafka en que todas las particiones devuelvan OffsetFetchResponsemensajes exitosos puede ser una fuente de tiempo de inactividad en el consumo.
  3. ¿Por qué Kafka a veces selecciona una réplica no sincronizada como réplica preferida durante las cargas del coordinador? ¿Cómo puedo reasignar líderes de partición a réplicas en el ISR?
  4. ¿Todas estas preguntas son discutibles porque debería usar una versión más nueva de Kafka?

Opciones de configuración del corredor:

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

Respuesta1

No he usado esa versión exacta de Kafka pero intentaré responder a las preguntas:

  1. Es posible que tenga habilitada la elección de líder impuro, depende de la cantidad de particiones frente a la cantidad de consumidores
  2. Puede, pero normalmente la integridad de la información es más importante que el tiempo de actividad en la mayoría de los sistemas MQ, siendo Kafka el que menos preocupaciones tiene.
  3. Establecer elección de líder impuro como falsa
  4. No lo sé, algunos de los conceptos siguieron siendo los mismos.

información relacionada