Kafka清理进程仅清理单个主题问题排查求助

以下是针对该问题的核心排查方向和解决方案，均基于Kafka 3.3.1的默认行为及Strimzi部署特性：

核心排查点 #

1. 消费组分区偏移的实际一致性 #

虽然你提到消费组已读取至最新偏移，但需确认每个主题的所有分区都满足CURRENT-OFFSET等于LOG-END-OFFSET：

• 执行命令：kafka-consumer-groups.sh --describe --group <你的消费组名称>
• 重点检查两个未清理主题的每个分区，若存在某分区偏移未追上日志末端，Kafka会保留该分区的所有旧日志（即使已过期），因为清理策略需保证消费组能回溯到已提交的偏移位置。

2. 日志分段的活跃状态与大小阈值 #

Kafka的delete清理策略仅会清理非活跃的、已过期的日志分段：

• 默认segment.bytes为1GB，若两个未清理主题的消息量极小，始终未达到分段大小阈值，就不会生成新的分段，旧分段会一直处于活跃状态，不会被标记为可清理。
• 验证方式：进入Kafka broker Pod（kubectl exec -it <broker-pod-name> -- bash），查看主题日志目录（路径通常为/var/lib/kafka/data/<topic-name>-<partition-id>），若仅存在一个初始分段文件（如00000000000000000000.log）且远小于1GB，即可确认此问题。

3. Strimzi主题的存储配置差异 #

即使主题的Kafka配置一致，Strimzi的KafkaTopic资源可能存在存储层面的差异：

• 执行命令：kubectl get kafkatopics <topic-name> -o yaml对比三个主题的spec字段，重点检查storage配置（如PV的读写权限、存储类特性），若未清理主题使用了只读或特殊存储介质，可能导致Kafka无法修改/删除日志文件。

4. 日志清理任务的触发记录 #

查看Kafka broker日志，搜索关键词Cleaning up segments for：

• 若未找到两个未清理主题的清理记录，说明清理任务未触发对这些主题的检查，可能是因为分段始终处于活跃状态，或集群负载过高导致清理线程优先级不足。

对应解决方案 #

1. 针对分段活跃状态问题：

   • 临时调整主题的segment.bytes参数（如设置为104857600即100MB），触发分段滚动：

     kafka-configs.sh --bootstrap-server <broker-address> --alter --topic <topic-name> --add-config segment.bytes=104857600
     

   • 或手动执行日志分段滚动：

     kafka-run-class.sh kafka.admin.LogRoller --bootstrap-server <broker-address> --topic <topic-name>
     

2. 针对偏移不一致问题：

   • 检查消费逻辑，确保每个分区的偏移都正确提交（避免异步提交丢失或漏提交）；
   • 若确认无业务影响，可重置消费组偏移至最新：

     kafka-consumer-groups.sh --bootstrap-server <broker-address> --group <group-name> --topic <topic-name> --reset-offsets --to-latest --execute
     

3. 针对存储配置问题：

   • 修改KafkaTopic资源的storage配置，确保使用与已清理主题一致的可读写存储卷；
   • 验证PV的权限设置，确保Kafka进程（通常用户为kafka）拥有日志目录的读写权限。

内容的提问来源于stack exchange，提问作者Scott Balmos