☰

Kafka 긴 코디네이터 로드 시간 및 작은 ISR

tag-icon • tag-icon kafka
Kafka 긴 코디네이터 로드 시간 및 작은 ISR

저는 Kafka 0.8.2.1을 사용하고 있으며, 200개의 파티션과 RF=3, 로그 보존이 약 1GB로 설정된 주제를 실행하고 있습니다.

알 수 없는 이벤트로 인해 클러스터가 "조정자 로드" 또는 "그룹 로드" 상태로 전환되었습니다. 몇 가지 신호를 통해 이러한 사실이 명백해졌습니다. pykafka 기반 소비자는 일부 파티션 하위 집합에 대해 FetchOffsetRequest오류 코드 14로 인해 s 동안 실패하기 시작했습니다. 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_offsets 오류로 인해 메시지 소비가 불가능해졌습니다. 코디네이터 로드가 계속 진행되는 동안 다른 소비자 그룹은 오류 없이 해당 주제를 사용할 수 있었습니다. 실제로 최종 수정 사항은 손상된 소비자를 새로운 Consumer_group 이름으로 다시 시작하는 것이었습니다.

질문

  1. 코디네이터 로드 상태가 6시간 동안 지속되는 것이 정상입니까 아니면 예상됩니까? 이 로드 시간은 로그 보존 설정, 메시지 생성 속도 또는 기타 매개변수의 영향을 받나요?
  2. pykafka가 아닌 클라이언트는 COORDINATOR_LOAD_IN_PROGRESS오류가 없는 파티션에서만 소비하여 처리합니까? 모든 파티션이 성공적인 결과를 반환한다는 Pykafka의 주장은 OffsetFetchResponse소비 중단 시간의 원인이 될 수 있습니다.
  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

답변1

나는 정확한 Kafka 버전을 사용하지 않았지만 다음 질문에 답변하려고 노력할 것입니다.

  1. 불결한 리더 선택이 활성화되었을 수 있습니다. 이는 파티션 수와 소비자 수에 따라 다릅니다.
  2. 그럴 수 있지만 일반적으로 대부분의 MQ 시스템에서는 가동 시간보다 정보 무결성이 더 중요합니다. Kafka는 가장 신경 쓰지 않는 시스템입니다.
  3. 부정한 리더 선택을 거짓으로 설정
  4. 잘 모르겠습니다. 일부 개념은 동일하게 유지되었습니다.

관련 정보