AWS MSK集群__consumer_offsets副本体积异常增大问题求助

原因分析 #

• 磁盘满导致副本同步中断与日志残留：当集群所有broker磁盘占满时，Kafka会暂停写入操作，包括副本同步的日志数据。扩容重启后，主副本已通过日志压缩（compact）清理了旧的消费偏移量记录，但异常副本在磁盘满期间无法同步主副本的清理动作，保留了大量未压缩的历史偏移量更新记录。后续同步仅追加新数据，旧的脏数据未被清理，导致体积暴增。
• __consumer_offsets清理机制的特殊性：该主题默认采用compact清理策略，依赖主副本压缩重复的消费组偏移量记录。若副本长时间无法同步主副本，它无法接收压缩后的日志段，只能保留原始的所有偏移量更新，而主副本已完成压缩，体积自然远小于异常副本。
• 重启后副本同步逻辑未触发截断：MSK重启后，异常副本可能未执行日志截断（truncation）来对齐主副本的最新日志状态，而是从上次中断的位置继续同步，导致未压缩的旧日志被完整保留。

解决方案 #

1. 强制异常副本重新同步（核心方案） #

通过分区重分配操作，让异常副本重新从主副本拉取完整的压缩日志：

• 生成分区重分配JSON文件，示例格式：

  {
    "version": 1,
    "partitions": [
      {
        "topic": "__consumer_offsets",
        "partition": <异常分区编号>,
        "replicas": [
          <主副本broker ID>,
          <其他正常副本broker ID>,
          <临时替换的broker ID>
        ]
      }
    ]
  }
  

• 执行重分配：

  kafka-reassign-partitions.sh --bootstrap-server <MSK_BOOTSTRAP_ENDPOINT> --reassignment-json-file reassign.json --execute
  

• 等待重分配完成（可通过--verify参数确认），再生成新的重分配计划将副本移回原broker，强制其重新同步主副本的压缩日志。

注意：操作前建议用kafka-consumer-groups.sh导出所有消费组的偏移量，避免意外数据丢失。

2. 优化__consumer_offsets的压缩配置 #

• 确认cleanup.policy已设置为compact（MSK默认配置，可通过kafka-configs.sh查询）：

  kafka-configs.sh --bootstrap-server <MSK_BOOTSTRAP_ENDPOINT> --describe --entity-type topics --entity-name __consumer_offsets
  

• 若消费组更新频繁，可调整min.cleanable.dirty.ratio（默认0.5）为更小值（如0.3），让压缩触发更频繁；或调小segment.ms（默认604800000，即7天），加快日志段滚动，减少单段体积。修改配置需通过MSK控制台或CLI提交配置更新请求。

3. 清理僵尸消费组 #

长期未活跃的消费组会留存大量无用的偏移量记录，增大__consumer_offsets体积：

• 列出所有消费组：

  kafka-consumer-groups.sh --bootstrap-server <MSK_BOOTSTRAP_ENDPOINT> --list
  

• 检查消费组状态，删除长期未活跃的僵尸组：

  kafka-consumer-groups.sh --bootstrap-server <MSK_BOOTSTRAP_ENDPOINT> --delete --group <僵尸消费组名称>
  

4. 完善监控告警 #

• 开启MSK的CloudWatch监控，重点关注BrokerDiskUsage、UnderReplicatedPartitions、ISRShrinks指标；
• 设置磁盘使用率告警阈值（如80%），避免再次出现磁盘占满导致的副本同步异常。

内容的提问来源于stack exchange，提问作者Slava Shpitalny