開篇扯犢子
今天踏進辦公聽到不是同事的早安，而是“有一個好消息，一個壞消息，你想聽哪個？” 我一愣，心想“大早上，就要玩刺激的嗎？” 但是還是淡定的回復說“無所謂，哥什么場面沒見過，直說吧，別繞彎子了” 但是心里已經開始慌了，哈哈，就是這么脆弱。。。
他說 “我們的 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 集群也恢復正常。
