前几天大概是脑子短路了，在zookeeper的client里面本想执行ls /kafka的，结果不小心执行成了rmr /kafka。

当时我的反应是这样的：

然后迅速查了下所有的线上服务，发现居然没有受到影响。然后我的反应是这样的：

虽然当时执行rmr /kafka时提示某个文件夹下面有文件，无法删除。但经过对比，发现还是有2处文件夹下面的文件全部删除了。1是/kafka/brokers/topics/*/；2是/kafka/consumers/*/offsets/*/。

对于第一处被删除文件夹，造成的最直接的影响就是，监控offset的脚本无法正确之行了。执行命令bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --group group-id --zkconnect kak1.et2/kafka --topic topic-name会报错，大概意思就是找不到broker。对于第二处被删除的文件夹，理论上应该不会造成任何影响，若采用老版本的consumer api，offset会持续的写入到zookeeper中，就算被删除了，等一会又会写入了；对于新版本的consumer api，直接与broker交互，不用写入offset到zookeeper中，所以更不会受到影响了。

此时通过命令bin/kafka-topics.sh --zookeeper zkhost:port --describe --topic topic_name可以发现，所有partition的leader都是none！那么现在问题来了，如何修复被删除的数据？

自己挖的坑含着泪也要填完。下面记录恢复被删除数据的方法。

首先执行命令：bin/kafka-topics.sh --zookeeper zkhost:port --describe --topic topic_name，会发现这时leader为none，isr为空。但Replicas的数据都还在，若Replicas也没有数据，那么下面的方法就不适合你了[哈哈哈哈哈哈...]。

然后在zookeeper的client里面执行下面的代码即可：

其中$topic_name替换为需要修复的topic name；controller_epoch可以通过在zkCli.sh里面执行get /kafka/controller_epoch命令得到；version默认1即可；leader_epoch默认0即可；isr的值和前面命令中得到的Replicas值一致即可；然后最重要的leader的值等于Replicas数组的第1个值即可。

就是这么简单。