前几天大概是脑子短路了,在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里面执行下面的代码即可:
|
create /kafka/brokers/topics/$topic_name/partitions null create /kafka/brokers/topics/$topic_name/partitions/0 null create /kafka/brokers/topics/$topic_name/partitions/1 null ... create /kafka/brokers/topics/$topic_name/partitions/0/state {"controller_epoch":38,"leader":1,"version":1,"leader_epoch":0,"isr":[1,3,4]} create /kafka/brokers/topics/$topic_name/partitions/1/state {"controller_epoch":38,"leader":2,"version":1,"leader_epoch":0,"isr":[2,4,5]} ... |
其中$topic_name替换为需要修复的topic name;controller_epoch可以通过在zkCli.sh里面执行get /kafka/controller_epoch命令得到;version默认1即可;leader_epoch默认0即可;isr的值和前面命令中得到的Replicas值一致即可;然后最重要的leader的值等于Replicas数组的第1个值即可。
就是这么简单。
楼主是在哪家公司工作,做的东西是我感兴趣的。
http://www.cnblogs.com/wgp13x/
现在在umeng
不错,不错,看看了!
Shiver me timbers, them's some great infaomrtion.
使用的网站模板在博客圈里没有第二个,是独一无二的。一定是站长自己写的了?文本边框蓝色发光,很酷!!!!!!!!!!!
We covdu'le done with that insight early on.
看看!
Kick the tires and light the fires, problem ofcaliifly solved!
Thank you for this blog, it was very helpful in troubleshooting my own issues.
It seems that no where else is this specific issue addressed!