Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 14. Scaling clusters by adding or removing brokers

Scaling Kafka clusters by adding brokers can increase the performance and reliability of the cluster. Adding more brokers increases available resources, allowing the cluster to handle larger workloads and process more messages. It can also improve fault tolerance by providing more replicas and backups. Conversely, removing underutilized brokers can reduce resource consumption and improve efficiency. Scaling must be done carefully to avoid disruption or data loss. By redistributing partitions across all brokers in the cluster, the resource utilization of each broker is reduced, which can increase the overall throughput of the cluster.

Note

To increase the throughput of a Kafka topic, you can increase the number of partitions for that topic. This allows the load of the topic to be shared between different brokers in the cluster. However, if every broker is constrained by a specific resource (such as I/O), adding more partitions will not increase the throughput. In this case, you need to add more brokers to the cluster.

Adding brokers when running a multi-node Kafka cluster affects the number of brokers in the cluster that act as replicas. The actual replication factor for topics is determined by settings for the default.replication.factor and min.insync.replicas, and the number of available brokers. For example, a replication factor of 3 means that each partition of a topic is replicated across three brokers, ensuring fault tolerance in the event of a broker failure.

Example replica configuration

default.replication.factor = 3
min.insync.replicas = 2
Copy to Clipboard Toggle word wrap

When you add or remove brokers, Kafka does not automatically reassign partitions. The best way to do this is using Cruise Control. You can use Cruise Control’s add-brokers and remove-brokers modes when scaling a cluster up or down.

  • Use the add-brokers mode after scaling up a Kafka cluster to move partition replicas from existing brokers to the newly added brokers.
  • Use the remove-brokers mode before scaling down a Kafka cluster to move partition replicas off the brokers that are going to be removed.

After removing a node from a Kafka cluster, use the kafka-cluster.sh script to unregister the node from the cluster metadata. Failing to unregister removed nodes leads to stale metadata, which causes operational issues.

Prerequisites

Before unregistering a node, ensure the following tasks are completed:

  1. Reassign the partitions from the node you plan to remove to the remaining brokers using the Cruise control remove-nodes operation.
  2. Update the cluster configuration, if necessary, to adjust the replication factor for topics (default.replication.factor) and the minimum required number of in-sync replica acknowledgements (min.insync.replicas).
  3. Stop the Kafka broker service on the node and remove the node from the cluster.

Procedure

  1. Unregister the removed node from the cluster: 

    /opt/kafka/bin/kafka-cluster.sh unregister \
  --bootstrap-server <broker_host>:<port> \
  --id <node_id_number>
    Copy to Clipboard Toggle word wrap

  2. Verify the current state of the cluster by describing the topics: 

    /opt/kafka/bin/kafka-topics.sh \
  --bootstrap-server <broker_host>:<port> \
  --describe
    Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat