【kafka】Corrupt index found index file last offset less than the base offset

1.概述

转载：Kafka重启出错：Corrupt index found

今天发现一台kafka broker宕掉，重启kafka broker集群发现日志中报如下错误，查阅各种资料，解决问题如下

一、出现的问题

Found a corrupted index file due to requirement failed: Corrupt index found, index file (/var/local/kafka/data/uws_topic-2/00000000000000254473.index) has non-zero size but the last offset is 254473 which is no larger than the base offset 254473.}. deleting /var/local/kafka/data/uws_topic-2/00000000000000254473.timeindex, /var/local/kafka/data/uws_topic-2/00000000000000254473.index and rebuilding index.. 

发现损坏的索引文件，在00000000000000254473.index中发现损坏的索引，索引的大小不是零，但是最后的offset是254473 ， 不大于基偏移量254473，需要删除254473.timeindex和254473.index，从新构建索引。

最后的offset是254473，基偏移量254473，最后的offset与基偏移量相等，二者相减等零才对，但相减索引的长度不是零，应该是零才对，所以判断索引就损坏了

另外附上一张kafka每个broker工作正常的图片（图中为3个broker、6个partition、3个replica）

二、解决问题

根据日志提示，我们需要手动删除每个partition下的 两个索引文件， 重新启动集群，kafka会自动重建索引文件

find /var/local/kafka -name "*.index" |xargs rm -f
find /var/local/kafka -name "*.timeindex" |xargs rm -f

三、出现的原因

出现此问题一般情况是Kafka Brokenr非正常关闭停止，导致索引损坏

因此需要了解一下Kafka log的格式及启动时候加载过程

Kafka log Segment的index文件格式：

首先需要指出，.index文件不是为每个消息都指定到物理位置的映射；举个例子，假设有20000~20009共10条消息，.index文件可配置为每条entry指定连续10条消息的物理位置映射，该例中，index entry会记录偏移量为20000的消息到其物理文件位置，一旦该条消息被定位，20001~20009可以很快查到。

每个entry大小8字节，定义了消息和其在文件中物理位置的映射；前4个字节是这个消息相对于该log segment第一个消息offset的相对偏移量，后4个字节是这个消息在log文件中的物理位置；

Kafka启动时加载log的步骤：

以一个partition log目录为例:：

1. 首先删除所有后缀名为.cleaned和.delete的文件：

2. 对于.swp结尾的文件，如果是log文件则直接恢复(去掉.swp, 变为.log)；如果是index文件直接删掉（然后rebuild index文件）；

3. 对于.index文件，如果没有对应的.log文件(同一个logSement其index和log的主文件名相同), 则删除该index文件；

4. 对于.log文件，加载如内存；如果其没有对应的.index文件（可能在第<2>步中被删除), 重新恢复其index文件；

5. 假设到这一步为止Kafka还没有加载到logSements, 说明该partition log目录下为空，一个新的log sement对象会被创建在内存；反之则转向第<6>步；

6. 如果Kafka已经加载到log, 最会开始recover log segments。至于为什么要recover log segments, 是因为大多数情况下，recover的目的就是检查Kafka上次关闭时是不是cleanShutDown （可通过检查partition log目录下是不是有后缀名为.kafka_cleanshutdown的文件确定）；

   • 如果是cleanShutDown(后缀名为.kafka_cleanshutDown的文件存在），则无需recover log segment；
   • 如果不是cleanShutDown, 则需要recover log segments；
   • 这里解释下什么是recover a log segment?
   • 在非cleanShutDown情况下， 一个log sement的log及index文件末尾可能有一些不合法的数据(invalid), 我们需要把它们截掉；
   • 首先要做的最简单检查，是log或index文件大小不能超过配置中设定的值（比方说一个.log文件中被设定最多保存10000条消息，超过10000条的都要抛弃掉）；

7. 最后做sanityCheck, 主要是检查每个log sement的index文件，确保不会加载一个出错的Log Segment；