现象
kafka版本：0.8.2
删除kafka的topic-dcs_storm_collect_info。这个topic之前一直在生产和消费，由于topic替换为另外的三组topic，该topic已经无用，为了及时释放磁盘空间，执行该topic的删除。但是删除未成功，topic被标记为marked for deletion（kafka已经配置了topic可删除，正常情况下应该可以删除topic和数据）
删除的目的是为了及时的清理数据，由于还有应用可能访问着这个topic，所以需要重建回来。但是这里没有实际删除掉，只是topic被标记了。于是希望将该topic彻底删除并重建。
执行手工删除：删除zk中的相应节点数据，删除文件系统中的相关数据文件。
重建topic，重建完成之后，执行kafka-describe命令，发现topic状态异常——leader为null，isr显示为空
查询资料，尝试手工恢复：往zk里手动写入该topic的元信息：leader是谁、isr是谁等
首先进入zk
zkCli.sh -server xxxx:22181
然后查看kafka的controller_epoch值
get /controller_epoch
假设我们要修复的topic是testDelete3，有三个分区，每个分组两个副本，共有三个节点，则依次执行：
create /brokers/topics/testDelete3/partitions null
create /brokers/topics/testDelete3/partitions/0 null
create /brokers/topics/testDelete3/partitions/1 null
create /brokers/topics/testDelete3/partitions/2 null
create /brokers/topics/testDelete3/partitions/0/state {“controller_epoch”:1,”leader”:1,”version”:1,”leader_epoch”:2,”isr”:[1，2]}
create /brokers/topics/testDelete3/partitions/1/state {“controller_epoch”:1,”leader”:2,”version”:1,”leader_epoch”:2,”isr”:[2，3]}
create /brokers/topics/testDelete3/partitions/2/state {“controller_epoch”:1,”leader”:3,”version”:1,”leader_epoch”:2,”isr”:[3，1]}
注意，
1、这里的controller_epoch的值，是上一步get到的
2、leader值要与topic信息的replica信息相关，isr和replica信息一致，leader选第一个节点就好。
3、version默认为1就好。
4、leader_epoch值不能一样
- 恢复之后，执行describe，显示状态正常，但是文件系统有问题：没有生成该topic的数据文件
- 执行生产者消费者测试，发现数据可以生产消费
- 观察日志，发现kafka定时清理任务报异常，由于是不关键topic（已经无人使用），没有重视
后果
插一句，埋下的坑，一定会给自己狠狠的踩到
- 三四天之后，收到运维报警，磁盘空间占用90%以上，查看文件使用情况，定位到是kafka的数据文件没有被清理
原因
- 查看日志，结合之前的隐患，很容易定位到，是因为kafka的日志清理机制存在缺陷，加上我们把那个topic给弄的有问题了，所以出现问题：每次定时清理机制启动，然后遍历所有的topic，去读取他们的segment文件创建时间和大小，根据配置的策略决定是否要清除。但是在当前的情况下，每次尝试去读那个问题topic的文件，就会报异常：文件不存在！这里作者一定是没有对循环遍历做异常控制，所以直接退出，其他的topic也不去清理了。最终导致一部分topic数据一直没有被清理。
惊险而又刺激的修复过程
由于磁盘告警，所以首先赶快重启了磁盘使用率最高的那个节点。重启其实并不能解决问题，只是希望释放一些磁盘，具体有没有效果未知。
果然，重启后并没有什么卵用。思考了下主要是因为那个topic的原因，所以决定彻底删除这个topic。当然执行步骤还是，先执行kafka delete的命令，然后手动去清除zk里的信息
接着，发现集群大量的报错，具体信息记不清了，异常信息大致是，找不到这个topic。但是进程还在，其他topic也可以工作，只是疯狂打日志。
由于整个kafka集群都在报错，慌了。赶快执行重建topic，尝试恢复。建好之后，发现日志不断的报另一类异常，一个是NotAssignedReplicaException，一个是UnknownTopicOrPartitionException，具体谁先谁后，由于情况紧急，已经不记得了。
百度到了类似的异常信息，供参考：https://blog.csdn.net/watermelonbig/article/details/78917730
[2017-12-27 18:26:09,267] ERROR [KafkaApi-2] Error when handling request Name: FetchRequest; Version: 2; CorrelationId: 44771537; ClientId: ReplicaFetcherThread-2-2; ReplicaId: 4; MaxWait: 500 ms; MinBytes: 1 bytes; RequestInfo: [test-topic02-rrt,12] -> PartitionFetchInfo(8085219,1048576),[test-topic01-ursr,22] -> PartitionFetchInfo(0,1048576),[test-topic02-rd,13] -> PartitionFetchInfo(787543,1048576),[test-topic02-st,12] -> PartitionFetchInfo(14804029,1048576),[test-topic04-ursr,7] -> PartitionFetchInfo(8,1048576),[test-topic04-rd,15] -> PartitionFetchInfo(2380092,1048576),[test-topic04-rrt,18] -> PartitionFetchInfo(27246143,1048576),[test-topic03-rrt,12] -> PartitionFetchInfo(12853720,1048576),[test-topic04-st,18] -> PartitionFetchInfo(25335299,1048576),[test-topic03-srt,11] -> PartitionFetchInfo(3750134,1048576),[test-topic05-ursd,17] -> PartitionFetchInfo(0,1048576),[test-topic05-srt,22] -> PartitionFetchInfo(33136074,1048576),[test-topic01-sd,1] -> PartitionFetchInfo(14361,1048576),[test-topic03-rd,21] -> PartitionFetchInfo(96366,1048576),[test-topic04-ursd,10] -> PartitionFetchInfo(0,1048576),[my-working-topic,15] -> PartitionFetchInfo(0,1048576),[test-topic02-ts_st,12] -> PartitionFetchInfo(0,1048576),[test-topic03-ursr,9] -> PartitionFetchInfo(1,1048576) (kafka.server.KafkaApis)
kafka.common.NotAssignedReplicaException: Leader 2 failed to record follower 4's position -1 since the replica is not recognized to be one of the assigned replicas for partition [my-working-topic,15].
[2017-01-06 21:05:56,730] ERROR [ReplicaFetcherThread-0-1], Error for partition [topic3,0] to broker 1:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
[2017-01-06 21:05:58,232] ERROR [ReplicaFetcherThread-0-1], Error for partition [topic3,0] to broker 1:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
[2017-01-06 21:05:59,733] ERROR [ReplicaFetcherThread-0-1], Error for partition [topic3,0] to broker 1:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
注：以上异常信息都是百度的，生产上遇到的和这个类似，只是具体集群和topic信息不一样。
WTF!!!
TMD彻底慌了，我觉得kafka集群快要挂了，于是准备请示下一步操作：重建kafka集群，即删除所有的数据和文件，重建topic。由于我们的业务是支持的，这些数据可以删，对其他应用的影响仅仅是短时的服务不可用，外部应用有开关，可以关闭对我们的服务依赖，所以可行（其实不可行也没办法，如果真挂了）。
同时也知道其实还是那个topic导致的原因，于是准备再试一试，删除那个topic，不恢复了。同时通知依赖这个topic的应用，关闭对它的依赖，并重启。具体的执行就是先执行kafka delete命令，然后删zk中的信息。
zkCli.sh -server XXXX:22181
rmr /brokers/topic/xxx
rmr /admin/delete_topic/xxx
rmr /config/topics/xxx
然后一个一个重启kafka节点——滚动重启，依次执行：
bin/kafka-sever-stop.sh
jps
由于数据读写且数据较大，这个过程可能会持续很久，不停的jps，直到进程消失
然后
nohup bin/kafka-server-start.sh config/server.properties >/dev/null 2>&1 &
启动kafka
观察日志，发现启动后，刚才提到的了两个异常就不报了。
依次执行其他的，节点。注意这里每次要等到当前重启的这个节点可以工作的时候，才重启下一个。
重启之后，还是在报之前找不到topic的那个异常，且速度很快。之后，我又电话联系了依赖这个topic的应用负责人，尝试重启那个应用。重启不是很成功，那个应用不断的core然后重启，于是赶快打电话让负责同事来支持。
没时间管了，我去沟通其他应用关闭开关的事情。大约二十几分钟之后，我回来，同事也到了，然后离奇的发现，集群好了。。。
检查磁盘空间，发现kafka清理机制已经恢复，磁盘大量释放～～～
其实已经不知道总结什么了，而且这种现象，很难复现。现在想想，根本原因还是那个topic导致的，之所以恢复，应该还是依赖以下几点：
- 有问题的topic被彻底清除了，且滚动重启了每个节点，因此这些节点也不再持有那个问题的topic信息，因此上面提到的那两种异常就没有了。
- 外部仍在使用这个topic的应用被及时关闭，这样就不会有相关的请求。虽然之前也没有读写请求，但也许还有一些心跳请求等。因此，报找不到topic的异常也没有了。
- 有问题的topic没有了，清理机制自然可以执行下去，于是自动清理了数据，释放了磁盘。
最后还想说几点教训：
- 不要执行非必要的操作。比如删除topic这种操作，一开始不执行，也没关系，没有数据写入之后，过几天存量数据会被kafka自动清理掉。
- 不要擅自更改topic在zk中的信息，以及手工删除topic，除非你准备重建整个topic
- 彻底掌握kafka的内部原理，和状态转换流程。如果可以，直接升级到高版本，以规避一些bug（比如遇到有问题的topic，自动清理机制就失效了，我认为这也是个bug）
好在有惊无险，记录下，警戒自己，也希望对有些人有帮助～
