我们计划将集群从 2 个节点扩展到 8 个节点。分区重新分配工具可以选择移动主题或分区。
对于 re-distribution 个分区,我计划按照以下步骤操作。
无论节点添加的数量如何,如果我在 topic-to-move.json 和下面命令中的所有代理中给出所有主题,那么它将在节点之间给出相等的分区分配吗?
bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-move.json --broker-list“0,1,2,3,4,5,6,7”--generate
在此之后我计划应用 json
--execute --reassignment-json-file generated-json 文件
这会导致任何问题吗?
这一步似乎更为通用,但为什么不以这种方式记录?
2 回答
有几点需要注意:
均匀分布分区不一定均匀分布数据。某些分区比其他分区拥有更多数据,因此您需要查看每个分区中的数据量,以便制定计划以在整个代理中均匀分布数据。如果您有单个分区主题或不均衡的键,则尤其如此。
是“机架意识”。如果 8 个代理商位于 3 个亚马逊可用区域或数据中心的两个不同电源或网络交换机上,那么请注意不要将领导者及其所有副本分发到相同的机架 ID 中,否则您将失去高可用性。
考虑使用复制配额。当您在代理之间移动大量数据时,它可能会从活跃的生产者和消费者那里夺走网络带宽。 Kafka 0.10 添加了单独的复制配额(带宽限制),以便您可以减少重新分配期间使用的带宽,因此它不会对您的实时客户端流量产生负面影响。只是油门太低或你的重新分配可能永远不会赶上来自生产者的新变化。
您可能需要考虑使用第三方工具来帮助自动构建重新分配计划。 Yahoo!的 Kafka Manager 具有重新分配功能(参见https://github.com/yahoo/kafka-manager/blob/master/README.md),Confluent 对其 Auto Rebalancer 进行了为期 30 天的免费试用,允许扩展和减少具有机架感知和限制重新分配的代理节点(请参阅http://docs.confluent.io/current/kafka/rebalancer/rebalancer.html)
通过将完整主题列表传递给工具,可能会重新分配所有分区。
在一个已经很大的集群(> 1000s 主题)中,这将导致大量不必要的数据复制和领导者选举。因此,通常您只提供主题的子集,并仅将新代理指定为目标,以最大限度地减少完成重新分配所需的工作。
如果您的群集足够小并且没有 GBs/TBs 数据,那么将所有主题传递给重新分配工具应该没问题,这可能是 easiest/fastest。