
我正在使用 Kafka 0.8.2.1,運行一個具有 200 個分區和 RF=3 的主題,日誌保留設定為大約 1GB。
未知事件導致叢集進入“協調器負載”或“群組負載”狀態。一些訊號顯示了這一點:基於 pykafka 的消費者在 s 期間開始失敗,某些分區子集的FetchOffsetRequest
錯誤代碼為 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_offsets錯誤導致訊息無法消費。當協調器負載仍在進行時,其他使用者群組能夠毫無錯誤地使用該主題。事實上,最終的解決方案是使用新的 Consumer_group 名稱重新啟動損壞的消費者。
問題
- 協調器負載狀態持續 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
答案1
我沒有使用過確切的 Kafka 版本,但我會嘗試回答以下問題:
- 您可能啟用了不乾淨的領導者選舉,這取決於分區數量與消費者數量
- 可以,但在大多數 MQ 系統中,資訊完整性通常比正常運行時間更重要,Kafka 是最無憂無慮的系統
- 將不乾淨的領導者選舉設為 false
- 我不知道,有些概念仍然是一樣的。