kafka集群扩容并且分区迁移,Kafka扩容
欢迎来到云社区，获取更多腾讯海量技术实践干货~
作者：mikealzhou
本文重点介绍kafka的两种常用数据迁移方法：1 .broker中不同数据磁盘间的分区数据迁移；2.不同代理之间分区数据迁移。
一、broker 1.1后台介绍不同数据磁盘间分区数据迁移近日，腾讯云某重要客户发现kafka broker中主题分区数据存储分布不均，导致部分磁盘100%耗尽，而部分磁盘只有40%的消耗。
分析显示，topic的部分分区数据集中在一些磁盘上，例如下面截图所示的/data5数据磁盘。
根据分布式系统的特点，很容易想到数据迁移的方法，将broker中不同数据磁盘的分区数据进行迁移。在线集群数据迁移之前，为了保证生产集群的数据完整性和安全性，需要在测试集群中进行测试。
1.2测试代理中不同数据磁盘分区数据迁移1.2.1建立测试主题，验证生产和消费正常。我们建立了一个测试集群。卡夫卡有三个经纪人，他们的主机名分别是tbds-172-16-16-11，TBDS-172-16-12，TBDS-172-16-12。每个代理配置两个数据磁盘，缓存的数据分别存储在/data/kafka-logs/和/data1/kafka-logs/中。
首先，确立测试主题：/Kafka-topics . sh-Create-Zookeeper TBDS-172-16-16-11:2181-Replication-Factor 2-Partitions 3-Topic Test _ Topic复制代码然后发送500条数据到Topic production，同时消耗数据。然后检查主题的分区数据：
组主题分区当前-偏移日志-结束-偏移滞后所有者组id1测试_主题0 172 172 0 Kafka-python-1 . 3 . 1 _ tbds-172-16-16-3/12.16.16.3组id 1测试_主题1 156 156 0 Kafka-python-1 . 3 . 1 _ tbds-172-16-3/172 . 16 . 16 . 3组id 1测试_主题2 172 172 0 Kafka-python-1
1.2.2在磁盘之间迁移分区数据。现在，登录到代理节点tbds-172-16-16-12，并将分区数据目录test _ topic/data1/Kafka-logs/test _ topic-0/移到/data/kafka-logs/:
在mv/data1/Kafka-logs/test_topic-0//data/Kafka-logs/copy code view/data/Kafka-logs/目录下，分区test _ topic-0的数据：
1.2.3再次测试题目的生产和消费数据。
再发500条数据，同时消耗数据。然后检查数据：
组主题分区当前-偏移日志-结束-偏移滞后所有者组id1测试_主题0 337 337 0 Kafka-Python-1 . 3 . 1 _ TBDS-172-16-16-3/172 . 16 . 16 . 3组id1测试_主题1 304 304 0 Kafka-Python-1 . 3 . 1 _ TBDS-172-16-16-3/72.16.16.3组ID 1测试_主题2 359 359 0 Kafka-Python-1再次检查tbds-172-16-16-12。
发现从/data1/kafka-logs/到/data/kafka-logs/目录下的分区数据目录test_topic-0/(即编号为0的分区)的缓存数据没有增加。
因为test_topic在每个分区中有两个副本，所以我找到了另一个编号为0的分区的副本数据，并将其存储在代理节点tbds-172-16-16-16中。登录代理节点TBDS-172-16-16，打开编号为0的分区缓存数据目录，获得以下信息：
发现代理节点TBDS-172-16-16的分区数据目录test_topic-0/中的缓存数据量在增加，即缓存了二产发送的消息数据。
可以看出，移动后的broker节点TBDS-172-16-12的编号为0的分区数据缓存目录中没有新的缓存数据。相应地，作为没有分区数据移动的代理节点的tbds-172-16-16-16在编号为0的分区缓存数据目录中有新添加的要再次发送的数据。
这是否意味着分区数据不能在代理磁盘之间移动？
1.2.4调用重启方案：重启kafka，重启kafka集群。重启后发现代理节点tbds-172-16-16-12的分区缓存数据目录中编号为0的数据也增加到了正常水平。
表示重启后，broker不同磁盘间的迁移数据已经生效。
1.2.5验证磁盘间迁移的分区数据生效，再次向test_topic发送500条数据，同时消耗数据，然后检查数据情况：
组主题分区当前-偏移日志-结束-偏移滞后所有者组id1测试_主题0 521 521 0 Kafka-Python-1 . 3 . 1 _ TBDS-172-16-16-3/172 . 16 . 16 . 3组id1测试_主题1 468 468 0 Kafka-Python-1 . 3 . 1 _ TBDS-172-16-16-3/12.16.16.3组id 1测试_主题2 511 511 0 Kafka-Python-1
发现两个复制品是相同的。
1.3结论在Kafka broker中，分区数据目录可以在不同的数据盘之间自由迁移。迁移完成后，重启kafka即可生效。
二、不同代理之间的分区数据传输kafka集群扩展时，新扩展的代理没有缓存数据，容易导致系统中数据分布不均匀。因此，有必要将原始集群代理的分区数据迁移到新扩展的代理节点。
通过使用kafka自带的kafka-reasign-partitions.sh脚本工具，可以实现不同broker之间转移分区数据。
在kafka测试集群原有三个经纪人的基础上，我们扩充了一个经纪人。
2.1获取test_topic的分区分布，执行命令：/Kafka-topics . sh-Zookeeper 172 . 16 . 16 . 11:2181-topic test_topic-describe复制代码得到test _ topic的3个分区(每个分区有2个副本)在3个broker节点的分布：
主题：测试主题分区计数：3复制因子：2配置：主题：测试主题分区：0主分区：1002副本：1002 Isr:1002，1001主题：测试主题分区：1主分区：1003副本：1003 Isr:1003，1002主题：测试主题分区：2主分区：1001副本：1001，1003 Isr: 1001编写分配脚本：move_kafka_topic.json，内容如下：
{ topics :[{ topic : test _ topic }]， version: 1}
执行分配计划生成脚本：/kafka-reassign-partitions . sh-zookeeper tbds-172-16-16-11:2181-topics-to-move-JSON-file/tmp/move _ Kafka _ topic . JSON-broker-list 1001，1002，1003，1004 -生成副本代码命令中的broker-list填写Kafka集群中四个代理的id。由于部署方法不同，不同的kafka集群具有不同的代理id。我们的测试集群代理id是1001、1002、1003和1004。读者需要根据自己的kafka集群设置的经纪人id来填写。
执行该命令后，将获得以下结果：
当前分区副本分配#当前分区的副本分配{version: 1， partitions :[{topic: test _ topic ， partition: 0， replicas: [1002，1001]}，{topic:test_topic ， partition:2， replicas:[1001，1003]}，{ topic : test _ topic ， partition:1， replicas:[1003，1002]}]}建议的分区分配配置#建议的分区分配{version: 1， partitions :[{ partitions将建议的分区分配配置复制并保存到文件move_kafka_topic_result.json:
{version:1， partitions :[{topic:test_topic ， partition:0， replicas:[1001，1002]}，{ topic : test _ topic ， partition:2， replicas:[1003，1004]}，{ topic: test _ topic ， partition:1， replicas:[1002，1003]}]}
2.3重新分发主题分区数据并执行重新分发命令：/Kafka-Reassign-partitions . sh-Zookeeper TBDS-172-16-16-11:2181-Reassign-JSON-file/tmp/move _ Kafka _ topic _ result . JSON-execute复制代码会得到以下结果：
当前分区副本分配{version:1， partitions :[{topic:test_topic ， partition:0， replicas:[1002，1001]}，{topic:test_topic ， partition:2， replicas:[1001，1003]}，{ topic : test _ topic ， partition:1， replicas:[1003，1002]}]}保存此选项，以便在回滚成功开始重新分配分区时用作-assignment-JSON-file选项{
2.4检查分区数据重新分配的进度，检查分配状态，并执行命令：/Kafka-Reassign-partitions . sh-Zookeeper TBDS-172-16-16-11:2181-Reassign-JSON-file/tmp/move _ Kafka _ topic _ result . JSON-verify复制代码得到结果：
分区重新分配的状态：分区[test_topic，0]的重新分配已成功完成分区[test_topic，2]的重新分配已成功完成分区[test _ topic，1]的分配已成功完成复制代码表明分区数据重新步进任务已完成。
2.5再次获取test_topic的分区分布，再次检查每个分区的分布，执行命令：/Kafka-topics . sh-Zookeeper 172 . 16 . 16 . 11:2181-topic test _ topic-describe复制代码获取返回结果：
主题：测试主题分区计数：3复制因子：2配置：主题：测试主题分区：0主分区：1002副本：1001，1002 Isr: 1002，1001主题：测试主题分区：1主分区：1003副本：1002，1003 Isr: 1003，1002主题：测试主题分区：2主分区：1003副本：1003，1004 Isr: 1003，1003从结果中可以看出，test_topic的分区数据已经从原来的三个经纪人重新分配到四个经纪人。
三。测试结论在Kafka Broker中分区数据目录可以在不同的数据盘之间自由迁移。迁移完成后，重启kafka即可生效；
Kafka可以在不同的broker之前迁移数据，这是通过使用Kafka自带的Kafka-reasign-partitions.sh脚本工具实现的。
四。修复客户的kafka集群故障。我们采用本文的测试方法，在客户Kafka集群的代理节点中，在不同磁盘之间迁移数据，并迁移多个主题的数据，最终实现数据缓存在磁盘之间的均匀分布。
同时，我们扩大了客户的kafka集群。扩展后，我们采用了本文描述的在不同代理之间迁移分区数据的方法，迁移多个主题的数据，保证了新扩展的节点也有缓存数据，减轻了原有代理节点的存储压力。
看卡夫卡操作总结。
卡夫卡设计原则
kafka和zookeeper有状态集群服务在kubernetes的部署实践(1)
本文经作者授权由贾云社区发表。请注明原文出处。
