// Module included in the following assemblies:
//
// configuring/assembly-reassign-tool.adoc

[id='proc-scaling-down-a-kafka-cluster-{context}']

= Reassigning partitions before removing brokers

[role="_abstract"]
Use a reassignment file generated by the `kafka-reassign-partitions.sh` tool to reassign partitions before decreasing the number of brokers in a Kafka cluster.
The reassignment file must describe how partitions are reassigned to the remaining brokers in the Kafka cluster.
You apply the reassignment specified in the file to the brokers and then verify the new partition assignments.
Brokers in the highest numbered pods are removed first.

This procedure describes a secure scaling process that uses TLS.
You'll need a Kafka cluster that uses TLS encryption and mTLS authentication.

The `kafka-reassign-partitions.sh` tool can be used to reassign partitions within a Kafka cluster, regardless of whether you are managing all nodes through the cluster or using the node pools preview to manage groups of nodes within the cluster.

NOTE: Though you can use the `kafka-reassign-partitions.sh` tool, Cruise Control is recommended xref:cruise-control-concepts-str[for automated partition reassignments and cluster rebalancing]. 
Cruise Control can move topics from one broker to another without any downtime, and it is the most efficient way to reassign partitions.

.Prerequisites

* You have a running Kafka cluster based on a `Kafka` resource configured with internal TLS encryption and mTLS authentication.
* You have xref:proc-generating-reassignment-json-files-{context}[generated a reassignment JSON file] named `reassignment.json`.
* You are running an interactive pod container that is connected to the running Kafka broker.
* You are connected as a `KafkaUser` configured with ACL rules that specify permission to manage the Kafka cluster and its topics.

.Procedure

include::snip-reassign-partitions.adoc[]

. When all the partition reassignments have finished, the brokers being removed should not have responsibility for any of the partitions in the cluster.
You can verify this by checking that the broker's data log directory does not contain any live partition logs.
If the log directory on the broker contains a directory that does not match the extended regular expression `[a-zA-Z0-9.-]+\.[a-z0-9]+-delete$`, the broker still has live partitions and should not be stopped.
+
You can check this by executing the command:
+
[source,shell,subs=+quotes]
kubectl exec my-cluster-kafka-0 -c kafka -it -- \
  /bin/bash -c \
  "ls -l /var/lib/kafka/kafka-log_<n>_ | grep -E '^d' | grep -vE '[a-zA-Z0-9.-]+\.[a-z0-9]+-delete$'"
+
where _n_ is the number of the pods being deleted.
+
If the above command prints any output then the broker still has live partitions.
In this case, either the reassignment has not finished or the reassignment JSON file was incorrect.

. When you have confirmed that the broker has no live partitions, you can edit the `Kafka.spec.kafka.replicas` property of your `Kafka` resource to reduce the number of brokers.
