其他分享
首页 > 其他分享> > Kafka重启出错:Corrupt index found

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;
<6.1> 这里解释下什么是recover a log segment?
在非cleanShutDown情况下, 一个log sement的log及index文件末尾可能有一些不合法的数据(invalid), 我们需要把它们截掉;
首先要做的最简单检查,是log或index文件大小不能超过配置中设定的值(比方说一个.log文件中被设定最多保存10000条消息,超过10000条的都要抛弃掉);
<7> 最后做sanityCheck, 主要是检查每个log sement的index文件,确保不会加载一个出错的Log Segment;

标签:index,log,文件,kafka,254473,Corrupt,Kafka
来源: https://www.cnblogs.com/zhangrui153169/p/16625539.html