Unclean leader election promotes a replica that is not in the in-sync replica (ISR) set when a partition leader fails and no eligible ISR remains. It restores the ability to write and consume, but the promoted replica may be missing messages, so data loss is expected. section 5.3 section 5.4
Normally, Kafka selects a replacement leader from the ISR. If the failed leader is the only ISR, the partition has no new leader by default: writes and reads stop rather than risk using stale data. section 5.3
Emergency recovery for a replicated topic
For products.prices.changelog.replication-3, first inspect the partition’s replicas and ISR membership. If the leader has failed and no ISR is available, an administrator can run kafka-leader-election.sh with --election-type=unclean for that topic. This should be limited to the affected topic, not applied across all topic partitions. The trade-off is explicit: service availability returns at the cost of potentially losing messages absent from the selected replica. section 5.3
Use unclean election only when the operational priority is clear:
- Treat it as an extreme-emergency action, not the normal response to broker failure. section 5.3
- Expect data loss because a non-ISR replica may not contain all messages. section 5.3
- Avoid enabling unclean.leader.election.enable as a general cluster policy unless accepting this reliability trade-off. section 5.3
$ kafka-topics.sh --describe \
--bootstrap-server localhost:9092 \
--under-replicated-partitions
Topic: products.prices.changelog.replication-3 Partition: 0
Leader: 2 Replicas: 2,3,1 Isr: 2,1
Topic: products.prices.changelog.replication-3 Partition: 1
Leader: 1 Replicas: 3,1,2 Isr: 1,2
Topic: products.prices.changelog.replication-3 Partition: 2
Leader: 1 Replicas: 1,2,3 Isr: 1,2
Inspect under-replicated partitions and compare each partition’s leader, replicas, and ISR before deciding whether emergency recovery is necessary. section 5.3
