1.1     分析导图

 

1.2    Topic的describe信息异常，出现大量的leader -1或者leader为none

• 通过1.4章节查看集群节点是否完整。查看kafka集群的节点是否有非常规退服。详情见4.1.14章节。如果出现这种情况，topic只能强制删除后重新创建，方法见维护宝典《如何手动删除topic》。
• 节点信息正常但是出现大量的leader出现-1或者none，需要从以下几个方向排查。
• Zookeeper上的分区数创建不完整：按照1.2章节登录zkCli后执行命令：

     ls /brokers/topics/异常topic名称/ 查看结果，如果为空，说明zk在创建partition节点时失败。如下图：

   

此时，如果需要临时恢复，需要手动创建partition目录命令如下，创建后切换controller：

create /brokers/topics/topicName/partitions

如果要彻底解决以上问题，有两个解决方法：

• 首先按照维护宝典《执行Kafka Topic创建操作，发现Partition的Leader显示为none》章节处理。
• 重启kafka集群。
• Zookeeper上的分区数创建完整，但是leader为-1：参照维护宝典《topic分区ISR存在存活副本，但是leader为-1》处理，或者打开集群的leader.election.enable 参数，动态修改该参数。

1.3    Topic分区状态良好但是无法读写数据

     1）判断当前节点是否有问题。

• 观察其它topic在本节点的写入流量是否正常，如果也不正常说明当前节点有问题，尝试重启节点看是否能够恢复。若能恢复需要再收集日志分析原因。
• 如果没有可以参考的其他业务，可以创建一个测试使用的单分区单副本的测试topic（手动指定模式），然后向该topic中写入测试数据，看是否存在读写异常。如果存在问题，尝试重启节点是否能够恢复

    2）如果节点没有问题，请收集日志进一步分析原因。

1.4    Topic分区状态良好但是无法读写数据

分区未同步主要原因有以下几点：

   1. 部分节点数据流量大，短时间内同步缓慢，分区不同步。

   通常可以通过查看下图曲线，正常情况下曲线的值为0：

通常情况下这种现象在业务的数据高峰期最为常见，当渡过数据高峰期后，曲线数值会变为0。

排查思路：

   1）排查每个节点上面的分区总数和leader总数和分区总数。

  可以参考kafka实例的曲线图。如果以下参数在每个节点的数量不均衡，可能导致数据热点。需要迁移部分分区。使整个集群分区总体均衡。

   

 2)  排查具体未完全同步的节点是哪几个。

找出哪些节点的分区没有同步。如下图：

可以看出，broker-3跟broker-1，broker-2无法同步，那么就要具体排查broker-3节点和broker-1节点上面的流量信息。如下图：

如果流量差异大，则重点排查节点上面是否存在分区少，但是流量大的topic。具体查找可以到具体的broker节点，找到具体的分区，如果存在，扩容分区即可。

2. 副本线程异常下线。

副本线程异常下线的恢复方法见《分区不均衡判定方法及解决方案.docx》。注意6.5.1~6.5.1.7版本可能存在副本异常下线的风险，该问题已经在6.5.1.8彻底解决。

1.5  Topic创建失败

1）如果是安全模式，需要使用的用户必须是带有kafkaadmin权限，或者带有管理角色的用户。

2）Zookeeper上节点创建失败。使用如下命令查看topic的节点的partition信息

ls /brokers/topics/topic名称

如下图：

此时说明partition节点没有创建成功。彻底恢复需要重启kafka集群。

临时规避方案：手动创建partitions节点，然后切换controller。

3）其它创建失败问题见维护宝典《Topic操作常见故障》

1.6  Topic删除失败

1）详情见维护宝典《执行Kafka Topic删除操作，发现无法删除》