Kafka分区所在broker宕机故障-引发该分区不可用

Posted 2023-03-01 每天译点晓知识

引入 | 记一次修复Kafka分区所在broker宕机故障-引发当前分区不可用的思考过程：

问题复现：

写在前面的话，在五一假期过后，业务组内童鞋碰到了这样一个问题，反复尝试并研究，包括不限于改Kafka，主题创建删除，Zookeeper配置信息重启服务等等，于是我们来一起看看，如何快速定位...

Ok，Now，我们还是先来一步步分析它并解决它，依然以”化解“的方式进行，我们先来看看业务进程中线程报错信息：org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-1, groupId=xxxx-center] 1 partitions have leader brokers without a matching listener, including [xxxx-xxxx-xxxx-message-0]

假设猜想：

从字面意思来看，当前分区所对应的的broker失去监听，怀疑是Kafka某个节点有问题-失联-假死？

思考过程：

从这个表象来看，某台机器有过宕机事件，宕机原因因环境而异，但Kafka的高可用性HA我们是耳熟能详的，为啥我们搭建的Kafka集群由多个节点组成，但其中某个节点宕掉，整个分区就不能正常使用-消费者端无法订阅到消息。

首先，我们来看下Kafka的配置信息：[root@xx-xx-xxx-xx kafka_2.11-2.1.1]# nohup  bin/kafka-server-start.sh config/server.properties &

这里使用了默认的topic分区副本数量：offsets.topic.replication.factor=1，当分区副本数量为1，则副本信息只会存在某一个broker节点，Isr即其自身。

这很容易出现单点故障，当当前节点挂了的时候，选举不出新的leader，导致分区不可用。在生产环境的话，可设置多个副本因子来保证高可用性（比如三个节点组成一个集群，副本数量为2，这样当任意一台节点丢失，kafka集群仍会正常工作Working...）。

解决方案：

当然，把这个宕掉的节点拉起来，查看该分区的信息leader:xxxx Isr:xxxx，保障生产者线程也能正常将数据入发送到Kafka中，消费者线程也能正常订阅到消息。

我们这里分布式协调服务采用的是Zookeeper，当Kafka某个broker节点宕调后，其实我们可以在Zookeeper中还是有迹可循的，因为Kafka集群的一些重要信息都记录在Zookeeper中：

引入上图->图片来源：http://blog.csdn.net/lizhitao/article/details/23744675

首先，我们来查看topic主题都有哪些，查询topic列表，进入kafka目录：
bin/kafka-topics.sh --list --zookeeper localhost:2181

然后，查询topic日志内容，跟业务进程中线程报错信息一致，进入kafka目录：
bin/kafka-console-consumer.sh --bootstrap-server xx.xx.xxx.xx:9092 --topic xxxx-xxxx-xxxx-message --from-beginning

接下来，查看当前topic详细信息，进入kafka目录：

bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic xxxx-xxxx-xxxx-message

在Kafka的server.properties配置文件中指定的broker.id=71已不在其中--从主题详细信息中，我们可以看到Partition，Leader，Replicas，Isr都为0...

接着，我们还是进入Zookeeper，查一下踪迹，进入Zookeeper目录：

./zkCli.sh -server localhost:2181

输入 ls /，查看到了Zookeeper中存储了brokers信息，
输入 ls /brokers，ls /brokers/topics，我们查看到了跟之前一致的topic列表，

输入 ls /brokers/ids，查看到ids [0]，这里broker.id的指定：在server.properties中修改broker.id可为当前机器后缀数值，不要超过其范围，保持日志中一致的话进入cd /home/user/kafka/logs，同样修改meta.properties文件，

而输入 ls /brokers/topics/xxxx-xxxx-xxxx-message/partitions/0/state，继续查看当前topic分区状态，

到了这里，我们已验证了之前的猜想，当前Broker节点下该分区没有查询到任何可用信息，配置文件中broker.id=71已被移除掉...

我们把这个宕掉的节点拉起来后，按上述步骤查看当前分区信息，这里我们上俩张成功后的图，保障了生产者线程也能正常将数据入发送到Kafka中，消费者线程也能正常订阅到消息。