kafka-集群缩容

一. 简述:

当业务增加时,服务瓶颈,我们需要进行扩容。当业务量下降时,为成本考虑。自然也会涉及到缩容。假设集群有 15 台机器,预计缩到 10 台机器,那么需要做 5 次缩容操作,每次将一个节点下线,那么现在问题就是如何正确、安全地从 Kafka 集群中移除一台 broker?搞定这个之后,重复 5 次即可(也可以根据实际情况,一次多台)。

一个 broker 下线,它上面的所有 partition 都会处于副本不足的状态,并且 Kafka 集群不会在其它的 broker 上生成这些副本,因此,在将一个 broker 从集群中移除之前,需要将这个 broker 上的 partition 副本都转移到最终会保留的 10 台机器上,怎么实现这个呢?Kafka 自带的分区重分配工具。

在集群数据量较大的情况下,分区的转移可能会花费较长时间,那么在转移过程中最好不要创建新 topic,不然新的 topic 有可能又创建到要被移除的 broker 上,当然如果实在无法避免的话,可以再对新的 topic 进行一次额外的转移。

二. 缩容步骤:

需要先获取所有 broker 的 broker id,选择待移除的 broker。 使用 kafka-reassign-partitions 脚本将待移除 broker 上的 partition 均匀地转移到最终会留在集群的 broker 上。确认待移除 broker 上没有任何 partition 之后,在 对这个 broker 进行停止和删除。其中重点是 partition 的转移或者说重分配。

  1. 获取brokerID :

可以通过管理工具,或者命令行,配置文件,都可以。 命令行的话:

复制代码
./kafka-broker-api-versions.sh --bootstrap-server localhost:9092

工具的话,cmak :

可以看到 broker list,broker id 分别为 141,142,145,146 ....

  1. 确定topic 数据量大小。

在重分区过程中,很耗节点资源的(cpu,内存,IO),所以如果数据量大,需要按批次进行多次操作。如果没有监控指标的话, 可以通过配置文件中,log.dir查看具体数据路径。通过指令(du -sh )判断topic的数据存储大小。

  1. 重分区 (和扩容方式一样,也可以参考: kafka-集群扩容-CSDN博客 ):

将涉及到的topic,以json方式,写入临时文件:

复制代码
{
  "version": 1,
  "topics": [
    {
      "topic": "topic1"
    },
    {
      "topic": "topic2"
    },
    ...
  ]
}

获取当前 partition 分配方案

使用 kafka-reassign-partitions 脚本的 --generate 来获取当前的 partition 分配方案。

复制代码
# bin/kafka-reassign-partitions.sh --bootstrap-server logkafka-1:9092 --topics-to-move-json-file topics-to-move.json --broker-list "141,142,143。。。" --generate

将新的分配规则保存在json文件(例如,保存在 reassignment.json这个文件下)然后,用--execute选项来执行它:

复制代码
bin/kafka-reassign-partitions.sh --bootstrap-server logkafka-1:9092 --reassignment-json-file reassignment.json --execute

可通过--verify 参数查看进度。

  1. 观察没问题后,直接下线空数据节点即可。

深耕运维行业多年,擅长linux、容器云原生、运维自动化等方面。

承接各类运维环境部署、方案设计/实施、服务代运维工作,欢迎沟通交流!

(V: xiaoxiangbj2013 ) !

相关推荐
q5673152332 分钟前
IBM官网新闻爬虫代码示例
开发语言·分布式·爬虫
不爱学英文的码字机器1 小时前
数据网格的革命:从集中式到分布式的数据管理新范式
分布式
优秀的颜4 小时前
计算机基础知识(第五篇)
java·开发语言·分布式
棠十一11 小时前
Rabbitmq
分布式·docker·rabbitmq
Lansonli12 小时前
大数据Spark(六十一):Spark基于Standalone提交任务流程
大数据·分布式·spark
Theodore_102213 小时前
大数据(2) 大数据处理架构Hadoop
大数据·服务器·hadoop·分布式·ubuntu·架构
Wo3Shi4七16 小时前
Kafka综合运用:怎么在实践中保证Kafka_高性能?
后端·kafka·消息队列
G探险者18 小时前
《深入理解 Nacos 集群与 Raft 协议》系列五:为什么集群未过半,系统就不可用?从 Raft 的投票机制说起
分布式·后端
G探险者18 小时前
《深入理解 Nacos 集群与 Raft 协议》系列一:为什么 Nacos 集群必须过半节点存活?从 Raft 协议说起
分布式·后端
G探险者18 小时前
《深入理解 Nacos 集群与 Raft 协议》系列四:日志复制机制:Raft 如何确保提交可靠且幂等
分布式·后端