问题的起因
最近做一次Kafka的副本数调整，从双副本调整为三副本时出现了一次副本不同步的问题，我们使用的kafka的版本为1.0.0，刚开始调整其他的topic时一起都工作正常，突然调整到其中一个不常用的topic时，这里假设为t1，调整指令为：
./kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file /tmp/t1.json --execute
发现调整总是不成功，通过verify指令查看：
./kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file /tmp/t1.json --verify
Status of partition reassignment:
Reassignment of partition t1-3 is still in progress
提示其中某个分区一直处于复制状态。
问题发展
刚开始以为只是数据没追上，没有意识到问题的严重性。等待观察了很长一段时间以后，
结果发现越来越多的分区开始副本脱离Isr，最严重的有很多分区Isr中只有一个成员了。
好在业务处理一直是正常的，没有受到影响。
问题与分析
整个问题处理和分析过程分为几个步骤：
第一步：尝试重新分配
操作步骤：
1）删除zk节点
rmr /admin/reassign_partitions
2）重新调用命令
./kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file /tmp/t1.json --execute
在这个过程中，发现有部分分区能够通过调整正常工作，但是有些分区无论怎么调整也无法正常工作。
这里我们开始怀疑是某几个节点有问题，有考虑重启这些节点来恢复kafka的想法。
由于这个是线上系统，并且数据量巨大，而且有好多分区Isr中只有一个，那么重启的风险不小。
第二步：发现问题
仔细查看每个节点的Kafka的日志文件内容，发现有部分broker上的日志中有以下错误日志：
2018-06-05 10:33:50,037|ERROR|ReplicaFetcherThread-1-4|kafka.utils.Logging$class.error:107|[ReplicaFetcher replicaId=0, leaderId=4, fetcherId=1] Error due to|
kafka.common.KafkaException: Error processing data for partition ycloud_cvod-4 offset 184090
at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$apply$2.apply(AbstractFetcherThread.scala:204)
at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$apply$2.apply(AbstractFetcherThread.scala:172)
at scala.Option.foreach(Option.scala:257)
at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1.apply(AbstractFetcherThread.scala:172)
at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1.apply(AbstractFetcherThread.scala:169)
at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply$mcV$sp(AbstractFetcherThread.scala:169)
at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply(AbstractFetcherThread.scala:169)
at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply(AbstractFetcherThread.scala:169)
at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:217)
at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:167)
at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:113)
at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:64)
同时我们发现controller.log文件长时间没有更新了，刚开始是怀疑可能是controller出问题了，在网上找了一下，发现kafka确实有一个bug：https://issues.apache.org/jira/browse/KAFKA-6666，这个bug需要把kafka升级到最新版本kafka1.1.0才能解决问题。由于线上已经有很多分区ISR成员只有一个，并且我们无法接受系统停止，所以无法接受关停Kafka进程进行升级的方案。
于是考虑调整controller，来尝试让同步工作恢复，我们进行了以下的操作步骤：
- 删除zk节点: /controller
很快，kafka集群重新分配了一个新的controller。
继续观察Isr中不全的副本的数据情况，发现数据仍然没有更新：
yuxianbing@KafkaMsg01:/data1/kafka/log4js$ ls -lrt /data*/kafka/logs/t1-9
total 16520620
-rw-rw-r-- 1 kafka kafka 0 Mar 22 15:11 leader-epoch-checkpoint
......
-rw-rw-r-- 1 kafka kafka 10485756 Jun 5 05:09 00000000189479366726.timeindex
-rw-rw-r-- 1 kafka kafka 10 Jun 5 05:09 00000000189479366726.snapshot
-rw-rw-r-- 1 kafka kafka 0 Jun 5 05:09 00000000189450811184.timeindex
-rw-rw-r-- 1 kafka kafka 60080 Jun 5 05:09 00000000189450811184.index
-rw-rw-r-- 1 kafka kafka 10485760 Jun 5 10:33 00000000189479366726.index
-rw-rw-r-- 1 kafka kafka 815836756 Jun 5 10:33 00000000189479366726.log
可以看到t1-9这个分区的副本文件一直没有变化，说明复制还是不正常；
第三步：再次重新分配
修改一下分区的副本所在的brokers，不要跟之前一致，然后执行
./kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file /tmp/t1.json --execute
验证分配结果：
./kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file /tmp/t1.json --verify
Status of partition reassignment:
Reassignment of partition t1-9 completed successfully
发现分配工作正常了。
于是按照这个思路，先把所有未跟上的分区重新进行分配。
第四步：均衡处理
由于第三步的工作只是让每个分区的副本能够重新与leader同步起来，但是整个kafka的分区分配就不均衡了，所以这里还需要重新对所有的分区进行均衡处理。
等待复制正常以后，所有分区的ISR都变成3个了，我们把kafka升级到1.1.0版本，整个处理过程结束。
问题总结
本次操作应该是触发了kafka的这个bug，不过从整个处理过程来看，遇事不能太着急，从各个方面去分析问题点，再加上各种可控范围内的尝试，最终达到了理想的处理结果。
另外对于开源的产品一定要及时跟进相关的issue list，及时针对有重大影响的问题就是修复和升级。
