记一次 Kafka 磁盘被写满的排查经历

开篇扯犊子

今天踏进办公听到不是同事的早安，而是“有一个好消息，一个坏消息，你想听哪个？” 我一愣，心想“大早上，就要玩刺激的吗？” 但是还是淡定的回复说“无所谓，哥什么场面没见过，直说吧，别绕弯子了” 但是心里已经开始慌了，哈哈，就是这么脆弱。。。

他说 “我们的 Kafka 集群挂了，磁盘被打满了”，我瞬间心跳飙升，然后他补充说 “好消息是测试环境”，我 ”你在跟我玩过山车吗，以后先说好消息“

虽说这是测试环境，但是还有好多甲方爸爸在用的，我得赶紧在他们开工之前先把环境恢复了呀。

迅速打开电脑，登录环境。。。这个过程中我回忆了一下，我貌似没有处理过这种问题，因为我们的生产环境是有告警的，是不可能让 Kafka 被写满的。

遇事不要慌，更何况是测试环境，。

先看一下监控指标，哦不对，Kafka 集群已经挂了，收集不到指标了。。。看🧶

算了直接登录环境，直截了当，找到数据最多的topic，删数据吧。哦，对了，这里提醒大家，Kafka 中 topic 是一个逻辑概念，真正放数据的地方是 topic 中的 partition。

清理数据

查看数据量较大的 partition

cd /data/kafka
du -h --max-depth=1 | sort -hr | head -10
# 然后根据情况清空 partition
rm -f <partition>/*
# 查看磁盘使用
df -Th

启动 Kafka

sudo systemctl start kafka

查看 Kafka 状态

tail -f /var/log/kafka/server.log

这时候发现了一个 broker 一直打印错误日志，而且无法执行 Kafka 命令行。

[2025-06-24 10:24:43,351] INFO [Admin Manager on Broker 89]: Error processing create topic request CreatableTopic(name='__consumer_offsets', numPartitions=30, replicationFactor=3, assignments=[], configs=[CreatableTopicConfig(name='compression.type', value='producer'), CreatableTopicConfig(name='cleanup.policy', value='compact'), CreatableTopicConfig(name='segment.bytes', value='41943040')]) (kafka.server.ZkAdminManager)
org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 3 larger than available brokers: 0.

这是一个三节点的 kafka 集群，为什么会有一个启动失败，看日志的信息是这个 broker 认为集群中只有它自己一个broker。那么大概率是与元数据有关系，元数据是存储在 zookeeper 中，那么看一下 zookeeper的状态吧。

排查解决问题

使用如下命令查看每个 zookeeper 集群中每个实例的状态，果然有一个实例的 Zxid 与其他两个是不同的，说明这个 zookeeper 集群发生了脑裂。当时解决问题太匆忙，没有截图。。。

echo stat|nc localhost 2181

解决办法是删除出问题的 zookeeper 的 epoch 文件，然后重启 zookeeper，让它重新加入集群并创建 epoch 文件。

cd /var/lib/zookeeper/version-2/
ls -l|grep Epoch
rm -f acceptedEpoch currentEpoch

重启 zookeeper 后，问题解决，再次查看 zookeeper 集群，已经正常，同时 kafka 集群也恢复正常。