kafka部分partition的leader=-1修复方案整理

发布于:2024-04-25 ⋅ 阅读:(38) ⋅ 点赞:(0)

1. 背景说明

部分环境发现,支撑kafka部分topic的被设置成单副本。当出现单机故障时,部分topic-partition出现leader=-1,对应的partition无法正常读写数据。特别是kafka内置的topic __consumer_offsets,__consumer_offsets 是记录topic的消费组数据消费的相关信息,如果出现了该问题,就会导致部分topic的消费组无法正常进行数据消费。

本文记录在工作中遇到的一次修复经历,并进行整理

2. 修复测试

2.1 创建正常的topic并验证生产和消费

  1. 获取kafka的配置zk链接信息,以及leader=-1的topic-partition、和每个kafka的id
# 获取kafka的id
cd /usr/local/services/kafka_2.11-1.1.1
cat config/server.properties |grep broker.id

在这里插入图片描述

# 获取kafka的zk地址
cd /usr/local/services/kafka_2.11-1.1.1
cat config/server.properties |grep zookeeper

在这里插入图片描述

  1. 创建一个单parition,4副本的topic,便于后续测试
# 创建topic
./bin/kafka-topics.sh --create --zookeeper $zk --topic test5 --replication-factor 4 --partitions 1

在这里插入图片描述

  1. 验证topic的读写情况
# 控制台1,创建数据消费者
./bin/kafka-console-consumer.sh --topic test5 --group test5 --bootstrap-server localhost:9092 --from-beginning


# 控制台2,创建数据生产者
./bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test5

在这里插入图片描述

2.2 停止kafka模拟leader=-1

  1. 停止部分kafka节点,使得__consumer_offsets的partition:41为-1(正好记录test5的数据消费信息)
# 停止相关kafka节点的计划任务
crontab -e

# 停止相关kafka进程
 ps -ef|grep kafka
 kill -9
# 获取zk信息
# 检查集群的topic信息
cd /usr/local/services/kafka_2.11-1.1.1
zk=xx.xx.xx.xx:2181/kafka
bin/kafka-topics.sh --zookeeper $zk --describe|grep __consumer_offsets

在这里插入图片描述

  1. 继续测试test5的数据生产和消费,此时test5无法消费数据
    在这里插入图片描述

2.3 修复parition

  1. 由于__consumer_offsets的partition:41(test5的消费记录保存在该paritition中)单副本,并且对应的节点已经宕机,因此不能通过调整副本的方式进行修复。需要调整zk中的元数据,重新给__consumer_offsets的partition:41配置isr和leader,让它恢复正常
# 获取zk信息
cd /usr/local/services/kafka_2.11-1.1.1
zk=xx.xx.xx.xx:2181/kafka

# 登录zk节点,并进入zk
cd /data/zookeeper-3.4.14/bin
./zkCli.sh

# 获取__consumer_offsets的partition:41的配置信息
get /kafka/brokers/topics/__consumer_offsets/partitions/41/state

# 调整__consumer_offsets的partition:41的配置信息,选择0作为leader
set /kafka/brokers/topics/__consumer_offsets/partitions/41/state {"controller_epoch":15,"leader":0,"version":1,"leader_epoch":177,"isr":[0]}

get /kafka/brokers/topics/__consumer_offsets/partitions/41/state

在这里插入图片描述

在这里插入图片描述

# 登录0号kafka节点,进一步调整replica信息,调整为0
cd /usr/local/services/kafka_2.11-1.1.1

vim replication-factor.json 
{"version":1,"partitions":[{"topic":"__consumer_offsets","partition":41,"replicas":[0],"log_dirs":["any"]}]}
# 执行调整命令
./bin/kafka-reassign-partitions.sh --zookeeper $zk --reassignment-json-file replication-factor.json --execute

# 查看调整进度
./bin/kafka-reassign-partitions.sh --zookeeper $zk --reassignment-json-file replication-factor.json --verify

说明调整完成,此时应该是leader:0 ,replica: [0], isr: [0]

# 获取zk信息
# 检查集群的topic信息
cd /usr/local/services/kafka_2.11-1.1.1
zk=xx.xx.xx.xx:2181/kafka
bin/kafka-topics.sh --zookeeper $zk --describe|grep __consumer_offsets

在这里插入图片描述

2.4 修复完成验证生产消费是否恢复

  1. 继续验证topic的生产和消费,已经恢复正常
# 控制台1,创建数据消费者
./bin/kafka-console-consumer.sh --topic test5 --group test5 --bootstrap-server localhost:9092 --from-beginning


# 控制台2,创建数据生产者
./bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test5

在这里插入图片描述

3. 疑问和思考

3.1 kafka在进行数据消费时,如果有partition的leader=-1,进行数据生产和消费时,kafka是否会自动剔除对应的parition?

不会。

在这里将kafka的topic-parition设置成2种类型。

  • 业务topic,业务数据进行生产和消费
  • 内置topic __consumer_offsets,记录业务topic的消费的offset信息

两者逻辑相同。

数据进行生产时,会通过的方式 hash(key) / partition数量(也可以指定partition)到对应的partition, 消费者跟对应的paritition对应才能保证数据在paritition内有序。

如果kakfa在进行hash时需要考虑partition的leader=-1的情况,对应的hash规则会发生调整,对应的数据消费端也需要进行调整,整体的影响较大,因此kafka没有进行这样的考虑。而是要求在创建topic时能够进行要求多副本,并且通过监控运维等手段及时发现leader=-1的partition,并及时修复。

4. 参考文档

暂无


网站公告

今日签到

点亮在社区的每一天
去签到