0

问题解决了。但是原因具体原因不能确定。如果有相同情况，可以按照这个思路排查看看。
我们服务器是arm架构，但是jdk没有使用arm架构的，替换了jdk版本后文件正常删除了。

问题解决了。但是原因具体原因不能确定。如果有相同情况，可以按照这个思路排查看看。
我们服务器是arm架构，但是jdk没有使用arm架构的，替换了jdk版本后文件正常删除了。

问题解决了。但是原因具体原因不能确定。如果有相同情况，可以按照这个思路排查看看。
我们服务器是arm架构，但是jdk没有使用arm架构的，替换了jdk版本后文件正常删除了。

他还有种可能是broker.id可能写重，导致一些脏数据（即使改回来，也已经污染了数据），使得kafka在决策的时候无法分辨。

接下来的排查，你可能需要打开清理日志，查看具体终止清理的原因了。看看是什么堵住了，导致一直不清理。kafka报cleaning is aborted and paused

如：

• 系统瓶颈，例如磁盘io满了
• kafka清理线程满了，没有多余的线程进行清理

每个segment的默认是1G，能看到日志文件已经有很多个了。这个topic的日志文件总的大小有两百多个G。而且文件数据有3个多月前的数据。理论上log.roll.ms+log.retention.hours=14天以后也会正常删除。

并且kafka节点在重启以后这些过期数据和删除的topic就会被正常删掉，这是我不能理解的地方。

我找到您之前回答的一个帖子，现象和这个帖子类似
类似帖

还有一些情况下，kafka是不会清理过期日志，你可以参考一下：

Kafka从不删除active segment（活跃段），也就是它将追加发送到分区的新消息的段。Kafka只删除旧段。当一个新的消息被发送到分区时，Kafka会将活跃段卷进一个旧的段，并且要么

• 包含新消息的活动段的大小将超过log.segment.bytes，或者

• 活跃段中第一条消息的时间戳超过log.roll.ms（默认是7天）。

你可以去消费一下那些不删除的topic，获取它的时间戳，如果时间戳大于7天，但是它依然在活跃的段，问题就是上面2个参数引起的，没有创新新的段。

log.retention.bytes,log.retention.hours,log.retention.minutes,log.retention.ms

这些参数是kafka的日志文件过期的时间。它是指在topic正常的情况下会删除过期的日志文件。

如果我通过命令 ：

./kafka-topics.sh --zookeeper localhost:2181  --delete --topic  my-topic

删除了topic，正常情况下会在下次轮询时log.retention.check.interval.ms删除的时候将topic的日志文件删掉。