-
Notifications
You must be signed in to change notification settings - Fork 144
module elect
The preferred leader election causes the cluster controller to select the "ideal" leader for each partition. Kafka has a narrow definition of what this is: it is the first replica listed in the replica list for the partition that is currently in sync. This means that the replica list for the partition is ordered, and the order matters. In a clean cluster, the first replica will always become the leader. This command is normally run after a broker has been shutdown and restarted, as it will cause the partitions to all move back to their proper leaders.
While there is a standard admin CLI tool for performing a preferred replica election, it does not always work. On some clusters, the number of partitions does not permit the PLE to run as the full partition list does not fit into a single Zookeeper znode (as the data exceeds the 1MB data limit). This tool takes that limitation into account and will split the PLE into multiple stages, with a pause between each one. In addition, it is sometimes desirable to split the work into multiple steps to stagger the restarting of replica fetchers on the brokers.
There are no options for the elect module.
All examples assume the cluster Zookeeper connect string is zook.example.com:2181/kafka/clustername
Example 1: Perform a preferred replica election in the cluster
kafka-assigner.py -z zook.example.com:2181/kafka/clustername -e elect
The elect module will always say that there are zero partition moves required. This is because the elect module does not move partitions, it only triggers the PLE.
If this module does not result in balanced leadership, and you already know the partitions are balanced across the cluster, you can use the reorder modules to perform leader election by reordering the replicas.