Kafka topic leader分区变为-1修复方法

Kafka基于发布-订阅模型，消息被发布到一个或多个主题（Topic）中，消费者可以订阅一个或多个主题来接收消息。每个主题都可以被分为多个分区（Partition），每个分区都是有序的，并且在多个节点之间进行了复制以提高可靠性。Kafka还支持对消息进行持久化存储，并且可以根据需要在分区和副本之间自动进行负载均衡和故障转移。

Kafka的应用场景非常广泛，包括实时日志收集、数据流处理、消息队列、事件驱动架构等。它可以与其他的大数据技术（如Hadoop、Spark、Storm等）进行无缝集成，提供可靠的数据流处理能力。

出现“leader -1”状态的原因可能是由于以下原因之一：

• 1）原来的leader副本发生故障，导致无法正常工作，例如服务器宕机、网络故障等。

• 2）发生了网络分区（network partition），导致leader副本无法与其他副本进行通信，从而无法处理消息。

• 3）分区副本同步失败，导致所有副本都失效，无法提供服务。

3.2 编写修复json文件尝试命令修复

• 尝试进行reassign:

/opt/cloudera/parcels/KAFKA/bin/kafka-reassign-partitions --zookeeper 

133.0.xxx.xxx:2181 --reassignment-json-file USP_ALLINFO.json --execute

3.3 等待一会发现未成功，虽然replicas已经有配置的节点了，但是leader并未生成

3.4 我们进行verify查看进度，发现任然在progress中

/opt/cloudera/parcels/KAFKA/bin/kafka-reassign-partitions --zookeeper 

133.0.xxx.xxx:2181 --reassignment-json-file USP_ALLINFO.json --verify

3.5 发现依然卡住，没有成功

此时我们进入zk查看5号分区的具体状态：

3.6 发现leader依然是-1，我们采用修改zk数据的方式进行手动分配5分区的leader

set /brokers/topics/USP_ALLINFO/partitions/5/state 

{"controller_epoch":241,"leader":92,"version":1,"leader_epoch":3,"isr":[92]}

再次检查主题状态，发现已经恢复正常：

3.7 此时手动写入几条数据，看是否能被5号分区成功收取

/opt/cloudera/parcels/KAFKA/bin/kafka-console-producer --
broker-list 133.0.xxx.xxx:9092 --topic USP_ALLINFO

共计写入10条，按kafka默认写入算法的话，10个分区应该每个分区会写入1条：

3.8 再次查看所有分球数据

3.9 写入成功

至此topic问题已修复完成，但是因为创建主题时，没有设置副本的问题依然存在，下次磁盘损坏时，依然会有丢数据的风险，我们需要对topic的所有分区增加副本，默认安全值是3，也就是1主2副本。

3.10 修改配置副本的json文件

3.11 采用命令修复

/opt/cloudera/parcels/KAFKA/bin/kafka-reassign-partitions --
zookeeper 133.0.xxx.xxx:2181 --reassignment-json-file 
USP_ALLINFO_rep.json --execute

生成，再次检查后，发现已生成完成，至此全部处理完成。

总 结：

当常规修复topic分区问题的方法失败时，可考虑使用从zookeeper上进行底层基础数据上进行修复，可解决kafka因版本问题或其他分区异常问题导致修复不成功的情况。

END