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

Posted 每天译点晓知识

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kafka分区所在broker宕机故障-引发该分区不可用相关的知识,希望对你有一定的参考价值。

引入 | 记一次修复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中,消费者线程也能正常订阅到消息。

以上是关于Kafka分区所在broker宕机故障-引发该分区不可用的主要内容,如果未能解决你的问题,请参考以下文章

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

Kafka的分区机制

分布式框架——Apache Kafka设计原理

kafka可以修改分区不

KafkaKafka设计原理详解

kafka极简入门(三)--创建topic