A Kafka partition has a leader broker. If that broker fails, the cluster controller detects the failure and starts an election to promote a replica. Clients may briefly wait for messages while the election completes. They then refresh their metadata and connect directly to the new leader. section 7.4
$ kafka-topics.sh --describe \
--topic products.prices.changelog.file-structure \
--bootstrap-server localhost:9092
Topic: products.prices.changelog.file-structure
TopicId: q4RDr2lTR8y1Wy6eYUpl6g PartitionCount: 3
ReplicationFactor: 3 Configs:
Topic: products.prices.changelog.file-structure Partition: 0
Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
Topic: products.prices.changelog.file-structure Partition: 1
Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
Topic: products.prices.changelog.file-structure Partition: 2
Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
Use `kafka-topics.sh --describe` to see each partition’s current leader and replicas. In this example, Broker 3 leads Partition 2. section 8.3.2
A failed leader returns
Stop Broker 3 with `kafka-broker-stop.sh 3`. Kafka elects a new leader for Partition 2. If Broker 3 restarts still believing it is leader, its old leader epoch gives it away: other brokers ignore messages carrying an outdated epoch. The epoch increases with each leader change so two brokers do not both act as the partition leader. section 8.3.2
$ kafka-leader-election.sh \
--election-type=preferred \
--all-topic-partitions \
--bootstrap-server localhost:9092
This command requests a preferred leader election for all topic partitions; it is distinct from the automatic election triggered by failure. section 8.3.2
Leader election depends on cluster coordination. KRaft coordinates within Kafka and is the recommended mechanism from Kafka 3.3 onward; earlier deployments used an external ZooKeeper ensemble. For a failed partition leader, the practical checks are its replacement in metadata and the epoch that prevents the former leader from distributing messages. section 4.3.1 section 8.3.2
