背景
在 2 月10 号下午大概 1 点半左右,收到用户方反馈,发现日志 kafka 集群 A 主题 的 34 分区选举不了 leader,导致某些消息发送到该分区时,会报如下 no leader 的错误信息:
In the middle of a leadership election,
there is currently no leader for this partition and hence it is unavailable for writes.
由于 A 主题 34 分区的 leader 副本再 broker0,另外一个副本由于速度跟不上 leader,已被踢出 ISR,0.11 版本的 Kafka 的 unclean.leader.election.enable 参数默认为 false,表示分区不可在 ISR 以外的副本选举 leader,导致了 A 主题发送消息持续报 34 分区 leader 不存在的错误,且该分区还未消费的消息不能继续消费了。
接下来运维在 kafka-manager 查不到 broker0 节点了处于假死状态,但是进程依然还在,重启了好久没见反应,然后通过 kill -9 命令杀死节点进程后,接着重启失败了,导致了如下问题。
Kafka 日志分析
查看了 KafkaServer.log 日志,发现 Kafka 重启过程中,产生了大量如下日志:
发现大量主题索引文件损坏并且重建索引文件的警告信息,定位到源码处:
kafka.log.OffsetIndex#sanityCheck
按我自己的理解描述下:
Kafka 在启动的时候,会检查 kafka 是否为 cleanshutdown,判断依据为 ${log.dirs} 目录中是否存在 .kafka_cleanshutDown 的文件,如果非正常退出就没有这个文件,接着就需要 recover log 处理,在处理中会调用 sanityCheck() 方法用于检验每个 log sement 的 index 文件,确保索引文件的完整性:
- entries:由于 kafka 的索引文件是一个稀疏索引,并不会将每条消息的位置都保存到 .index 文件中,因此引入了 entry 模式,即每一批消息只记录一个位置,因此索引文件的 entries = mmap.position / entrySize;
- lastOffset:最后一块 entry 的位移,即 lastOffset = lastEntry.offset;
- baseOffset:指的是索引文件的基偏移量,即索引文件名称的那个数字。
索引文件与日志文件对应关系图如下:
判断索引文件是否损坏的依据是:
_entries == 0 || _lastOffset > baseOffset = false // 损坏
_entries == 0 || _lastOffset > baseOffset = true // 正常
这个判断逻辑我的理解是:
entries 索引块等于零时,意味着索引没有内容,此时可以认为索引文件是没有损坏的;当 entries 索引块不等于 0,就需要判断索引文件最后偏移量是否大于索引文件的基偏移量,如果不大于,则说明索引文件被损坏了,需要用重新构建。
那为什么会出现这种情况呢?
我在相关 issue 中似乎找到了一些答案:
- https://issues.apache.org/jira/browse/KAFKA-1112
- https://issues.apache.org/jira/browse/KAFKA-1554
总的来说,非正常退出在旧版本似乎会可能发生这个问题?
有意思的来了,导致开机不了并不是这个问题导致的,因为这个问题已经在后续版本修复了,从日志可看出,它会将损坏的日志文件删除并重建,我们接下来继续看导致重启不了的错误信息:
<