ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

Kafka重启出错:Corrupt index found

2022-08-25 20:00:37  阅读:138  来源: 互联网

标签:index log 文件 kafka 254473 Corrupt Kafka


 

 

今天发现一台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

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有