Leader election in Kafka - Commands & Configuration

Introduction

Leader election is the process where Kafka brokers decide which broker will manage a partition's operations. This ensures only one broker coordinates reads and writes for a partition, preventing conflicts and data loss.

When a Kafka broker fails and another broker must take over as leader for its partitions.

When adding new brokers to a Kafka cluster and leaders need to be balanced across them.

When manually triggering leader re-election to improve cluster performance or fix stuck leaders.

When monitoring cluster health and verifying leader assignments for partitions.

When performing maintenance on brokers and needing to move leadership away from them.

Commands

This command shows the current leader and replicas for each partition of 'my-topic'. It helps verify which broker is leader before and after leader election.

Terminal

kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic my-topic

Expected Output

Topic: my-topic	PartitionCount: 3	ReplicationFactor: 2	Configs: 

	Topic: my-topic	Partition: 0	Leader: 1	Replicas: 1,2	Isr: 1,2

	Topic: my-topic	Partition: 1	Leader: 2	Replicas: 2,3	Isr: 2,3

	Topic: my-topic	Partition: 2	Leader: 3	Replicas: 3,1	Isr: 3,1

→

--bootstrap-server - Specifies the Kafka broker to connect to

→

--describe - Shows detailed information about the topic partitions

→

--topic - Specifies the topic to describe

This command triggers a preferred leader election, moving leadership to the preferred replicas for partitions. Useful to rebalance leaders after broker recovery or maintenance.

Terminal

kafka-preferred-replica-election.sh --bootstrap-server localhost:9092

Expected Output

Starting preferred replica leader election for partitions in all topics.

Preferred replica leader election completed successfully.

→

--bootstrap-server - Specifies the Kafka broker to connect to

Run again to verify that the leader for each partition has changed to the preferred replica after the election.

Terminal

kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic my-topic

Expected Output

Topic: my-topic	PartitionCount: 3	ReplicationFactor: 2	Configs: 

	Topic: my-topic	Partition: 0	Leader: 2	Replicas: 1,2	Isr: 1,2

	Topic: my-topic	Partition: 1	Leader: 2	Replicas: 2,3	Isr: 2,3

	Topic: my-topic	Partition: 2	Leader: 3	Replicas: 3,1	Isr: 3,1

→

--bootstrap-server - Specifies the Kafka broker to connect to

→

--describe - Shows detailed information about the topic partitions

→

--topic - Specifies the topic to describe

Key Concept

If you remember nothing else from leader election, remember: only one broker leads a partition at a time to keep data consistent and available.

Common Mistakes

Running preferred replica election without checking current leaders

You might trigger unnecessary leader changes causing temporary unavailability or load spikes.

Always describe topic partitions first to understand current leader distribution before triggering election.

Not specifying the correct bootstrap server address

The command will fail to connect or affect the wrong Kafka cluster.

Use the correct --bootstrap-server address matching your Kafka cluster.

Expecting leader election to fix all partition issues automatically

Leader election only changes leadership; it does not fix underlying broker or network problems.

Investigate broker health and network status if leader election does not resolve issues.

Summary

Use kafka-topics.sh --describe to check current partition leaders.

Trigger leader election with kafka-preferred-replica-election.sh to move leadership to preferred brokers.

Verify leader changes by describing the topic partitions again.

Practice

1. What is the main purpose of leader election in Kafka?

easy

A. To backup data to external storage

B. To balance the load evenly among all brokers

C. To choose one broker to lead and coordinate tasks

D. To monitor client connections

Solution

1. Step 1: Understand leader election role

   Leader election picks one broker as the leader to manage partition tasks.

2. Step 2: Compare options

   Only To choose one broker to lead and coordinate tasks describes choosing a broker to lead and coordinate tasks, which matches Kafka's leader election purpose.

3. Final Answer:

   To choose one broker to lead and coordinate tasks -> Option C

4. Quick Check:

   Leader election = choose leader broker [OK]

Hint: Leader election picks one leader broker, not all brokers [OK]

Common Mistakes:

• Confusing leader election with load balancing
• Thinking leader election backs up data
• Assuming leader election monitors clients

2. Which of the following is the correct way to configure Kafka broker IDs for leader election?

easy

A. broker.id=unique_integer_per_broker

B. broker.id=localhost

C. broker.id=auto_assign

D. broker.id=0.0.0.0

Solution

1. Step 1: Identify broker ID type

   Kafka requires each broker to have a unique integer ID for leader election.

2. Step 2: Check options

   Only broker.id=unique_integer_per_broker uses a unique integer, while others use invalid or non-integer values.

3. Final Answer:

   broker.id=unique_integer_per_broker -> Option A

4. Quick Check:

   Broker ID must be unique integer [OK]

Hint: Broker ID must be a unique integer, not a string or IP [OK]

Common Mistakes:

• Using hostnames or IPs as broker IDs
• Setting broker.id to zero or non-unique values
• Assuming auto assignment works without config

3. Given the following Kafka cluster state, which broker will be the leader for partition 0?

Broker 1: ISR = [1, 2, 3]
Broker 2: ISR = [1, 2, 3]
Broker 3: ISR = [1, 2, 3]
Current leader: Broker 2
Broker 2 fails

medium

A. Broker 2

B. Broker 1

C. Broker 3

D. No leader assigned

Solution

1. Step 1: Understand ISR and leader failover

   ISR (In-Sync Replicas) are eligible leaders. When current leader fails, next ISR broker becomes leader.

2. Step 2: Identify next leader after Broker 2 fails

   Broker 1 and 3 are in ISR. Kafka picks the lowest broker ID in ISR as new leader, so Broker 1.

3. Final Answer:

   Broker 1 -> Option B

4. Quick Check:

   Next leader = lowest ISR broker after failure [OK]

Hint: Leader election picks lowest ISR broker if current leader fails [OK]

Common Mistakes:

• Choosing failed broker as leader
• Picking broker outside ISR
• Assuming no leader assigned after failure

4. You have a Kafka cluster where leader election is not working properly. Which of the following is the most likely cause?

medium

A. Each broker has a unique broker.id

B. Zookeeper is running and connected

C. Partitions have multiple replicas

D. All brokers have the same broker.id

Solution

1. Step 1: Identify leader election requirements

   Leader election requires each broker to have a unique broker.id to distinguish them.

2. Step 2: Analyze causes

   If all brokers share the same broker.id, leader election cannot assign a unique leader, causing failure.

3. Final Answer:

   All brokers have the same broker.id -> Option D

4. Quick Check:

   Unique broker IDs needed for leader election [OK]

Hint: Check broker IDs; duplicates break leader election [OK]

Common Mistakes:

• Assuming Zookeeper connection causes failure
• Thinking multiple replicas cause election failure
• Ignoring broker.id uniqueness

5. In a Kafka cluster using KRaft mode (without Zookeeper), how does leader election differ from the traditional Zookeeper-based approach?

hard

A. KRaft uses an internal quorum of controllers to elect leaders without external Zookeeper

B. KRaft requires manual leader assignment by the admin

C. KRaft disables leader election and uses round-robin partition assignment

D. KRaft uses Zookeeper but with a different election algorithm

Solution

1. Step 1: Understand KRaft mode leader election

   KRaft mode replaces Zookeeper with an internal controller quorum that manages leader election.

2. Step 2: Compare options

   Only KRaft uses an internal quorum of controllers to elect leaders without external Zookeeper correctly states KRaft uses internal quorum without external Zookeeper for leader election.

3. Final Answer:

   KRaft uses an internal quorum of controllers to elect leaders without external Zookeeper -> Option A

4. Quick Check:

   KRaft = internal quorum leader election [OK]

Hint: KRaft replaces Zookeeper with internal controller quorum [OK]

Common Mistakes:

• Thinking KRaft disables leader election
• Assuming manual leader assignment in KRaft
• Believing KRaft still uses external Zookeeper