大数据-65 Kafka 高级特性 分区 Broker自动再平衡 ISR 副本 宕机恢复再重平衡 实测

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
注册配置 MSE Nacos/ZooKeeper,182元/月
云原生网关 MSE Higress,422元/月
简介: 大数据-65 Kafka 高级特性 分区 Broker自动再平衡 ISR 副本 宕机恢复再重平衡 实测

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(正在更新…)

章节内容

上节我们完成了如下的内容:

我们模拟了让分区重新分配的过程,在业务上实际发生的情况。比如:当几台Kafka节点不够用后,我们将对Kafka进行扩容,但是此时遇到的问题是,之前的分区不会分配到新的Kafka节点上,那此时我们需要借助Kafka提供的脚本来实现这一过程:


Kafka分区重分配

包含启动服务、创建主题、新增服务等操作

查看集群、生成JSON、执行计划

最终确认完成了新加Kafka节点后,分区进行了重分配。

71c156a8c723514c980b4661190122a1_aef5e0fa85d94842b2fdbea1cab6191c.png

Kafka启动再平衡

我们可以在新建主题的时候,手动指定主题各个Leader分区以及Follower分区的分配情况,即什么分区副本在哪个Broker节点上

随着系统的运行,Broker的宕机重启,会引发Leader分区和Follower分区的角色转换,最后可能Leader大部分都集中在少数几台Broker上,由于Leader负责客户端的读写操作,此时集中Leader分区的少数几台服务器的网络IO和CPU都会很紧张。


Leader和Follower的角色转换会引起Leader副本在集群中分布的不均衡,此时我们需要一种手段,让Leader的分布重新恢复到一个均衡的状态。


启动服务

目前我们需要启动两台Kafka进行测试:

分别在h121 和 h122节点上启动服务

h121

h122

新建主题

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --create --topic topic_test_01 --replica-assig

该命令的解释:

  • 创建了主题 topic_test_01
  • 有三个分区,每个分区两个副本

创建的结果如下图:

查看主题

我们可以通过如下的命令进行查看:

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

执行结果如下图:

主题信息

主题名称 topic_test_01

分区数 3

复制因子 2

分区详情

分区0:


Leader 0

副本 0,1

ISR(同步副本集合)0,1

分区1:


Leader 1

副本:1,0

ISR(同步副本集合)1,0

分区2:


Leader 0

副本 0,1

ISR(同步副本集合)0,1

模拟宕机

停止节点

我们结束掉 h122 的机器的Kafka

此时查看我们的主题信息:

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

运行结果如下图所示:

分析解释

通过对比我们可以看到,Leader已经全是0了,且ISR为0了。

分区0、1、2的Leader都变成了Broker的Broker0接管了所有分区的Leader角色。

所有分区的ISR现在只包含Broker0,原来包含的Broker1已经从ISR中移除,这表明只有Broker0目前保持同步状态。

副本状态中,尽管Replicase任列出0、1或1、0,但由于Broker1已经停止,实际上只有Broker0保持活跃。

重启节点

我们在刚才停掉的 h122 节点上,重新启动Kafka服务:

kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

重新启动后,h122是Broker1,继续查看主题的分区:

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

观察结果如下:

根据对比,我们发现,Broker恢复了,但是Leader的分配并没有改变,还是出于Leader切换后的状态。

分区还是3个,副本也正常,ISR也正常,但是唯独Leader这一项,会发现都是Broker0,而没有Broker1。

这种问题我们需要让Kafka自动平衡一下。


自动再平衡

脚本介绍

此时,我们需要使用Kafka自动再平衡的脚本:kafka-preferred-replica-election.sh

我们直接运行,可以看到脚本的介绍:

kafka-preferred-replica-election.sh
• 1

脚本的介绍如下图:

编写JSON

我们编写JSON,这样编写是因为我们开始配置的时候是:

在逗号分割的每个数值对儿中:

● 排在前面的是Leader分区

# 这是我们希望的分区状况
--replica-assignment "0:1,1:0,0:1"

所以我们编写的JSON内容如下:

vim topic_test_01_preferred-replica.json


{
  "partitions": [
    {
      "topic": "topic_test_01",
      "partition": 0
    },
    {
      "topic": "topic_test_01",
      "partition": 1
    },
    {
      "topic": "topic_test_01",
      "partition": 2
    }
  ]
}

写入的内容如下图所示:

运行测试

执行如下的脚本:

kafka-preferred-replica-election.sh --zookeeper h121.wzk.icu:2181 --path-to-json-file topic_test_01_preferred-replica.json

运行后返回的结果如下:

查看分区

我们再次查看分区:

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01
• 1

执行的结果如下图所示:

我们可以观察到,此时的Leader中,已经重新平衡了:Leader0、Leader1、Leader0。

目录
相关文章
|
10月前
|
存储 SQL 分布式计算
大数据散列分区映射到分区
大数据散列分区映射到分区
134 4
|
10月前
|
存储 负载均衡 算法
大数据散列分区计算哈希值
大数据散列分区计算哈希值
157 4
|
10月前
|
大数据 数据管理 定位技术
大数据散列分区选择分区键
大数据散列分区选择分区键
117 2
|
10月前
|
分布式计算 负载均衡 监控
大数据增加分区数量
【11月更文挑战第4天】
132 3
|
10月前
|
负载均衡 大数据
大数据散列分区查询频率
大数据散列分区查询频率
93 5
|
10月前
|
存储 大数据 数据处理
大数据散列分区数据分布
大数据散列分区数据分布
105 2
|
10月前
|
存储 负载均衡 监控
大数据散列分区数据分布
大数据散列分区数据分布
120 1
|
10月前
|
存储 大数据 数据管理
大数据分区注意事项
大数据分区注意事项
162 5
|
10月前
|
存储 SQL 分布式计算
大数据如何增加分区
大数据如何增加分区
173 5
|
10月前
|
存储 大数据 数据管理
大数据分区简化数据维护
大数据分区简化数据维护
119 4

热门文章

最新文章