server.log中有两种日志条目
第一种：
WARN由于__consumer_offsets-6偏移量903无效，因此将checkpointed的第一脏偏移量重置为记录起始偏移量918。 （kafka.log.LogCleanerManager$）
第二种：
INFO [TransactionCoordinator id=3] Initialized transactionalId Source: AppService Kafka consumer -> Not empty string filter -> CDMEvent mapper -> (NonNull CDMEvent filter -> Map -> Sink: Kafka CDMEvent producer, Nullable CDMEvent filter -> Map -> Sink: Kafka Error producer)-bddeaa8b805c6e008c42fc621339b1b9-2 with producerId 78004 and producer epoch 23122 on partition __transaction_state-45 (kafka.coordinator.transaction.TransactionCoordinator)
我发现一些建议提到删除检查点文件可能会有所帮助：
https://medium.com/@anishekagarwal/kafka-log-cleaner-issues-80a05e253b8a
“我们收集到的是：
停止经纪人
删除日志清理器检查点文件
( cleaner-offset-checkpoint )
启动经纪人
为我们解决了问题。”
对所有检查点文件(cleaner-offset-checkpoint, log-start-offset-checkpoint, recovery-point-offset-checkpoint, replication-offset-checkpoint)进行尝试是否安全？还是不建议对所有检查点文件进行尝试？
答案 0 :(得分：1)
我已经停止了每个经纪人，并将cleaner-offset-checkpoint移到了备份位置，并在没有该文件的情况下启动了它，经纪人巧妙地启动了，删除了很多多余的段，并且它们没有记录：
WARN由于检查点偏移量无效，因此将__consumer_offsets的第一个脏偏移量重置为记录起始偏移量
显然，这个问题/缺陷https://issues.apache.org/jira/browse/KAFKA-6266甚至在2.0中都还没有解决。 2.但是，这并没有按照期望压缩消费者偏移量，即offsets.retention.minutes的默认值为10080（7天），我试图将其明确设置为5040，但是它没有帮助，仍然存在消息已存在一个月以上，因为log.cleaner.enable默认情况下为true，因此应该对其进行压缩，但实际上并非如此，唯一的尝试是将cleanup.policy设置为针对__consumer_offsets主题再次删除，但这是触发问题的操作，所以我有点不愿意这样做。我在此处No Kafka Consumer Group listed by kafka-consumer-groups.sh中描述的问题也不能通过此方法解决，显然存在某种阻止kafka-consumer-groups.sh读取__consumer_offsets主题的问题（当使用--bootstrap-server选项发出时，否则它将读取该问题）。 （来自zookeeper）并显示结果，这就是Kafka Tool可以毫无问题地完成的工作，我相信这两个问题是有联系的。 我认为该主题未压缩的原因是，根据代理设置，该主题的消息具有完全相同的密钥（甚至是时间戳），且早于其应有的时间。 Kafka工具还忽略某些记录，并且在该显示中不会将它们解释为消费者组。为什么kafka-consumer-groups.sh忽略所有内容，可能是由于这些记录的某些损坏。