Kafka 节点重启失败导致数据丢失的分析排查与解决之道

背景

在 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

总的来说，非正常退出在旧版本似乎会可能发生这个问题？

有意思的来了，导致开机不了并不是这个问题导致的，因为这个问题已经在后续版本修复了，从日志可看出，它会将损坏的日志文件删除并重建，我们接下来继续看导致重启不了的错误信息：