Kafka滚动升级期间test分区无法获取Leader问题求助

问题场景 #

• 集群配置：3个Kafka Pod（kafka-0、kafka-1、kafka-2），test主题副本因子设为2
• 升级路径：从Kafka 2.2.1（对应Confluent Platform 5.2.2）滚动升级至3.2.0（对应Confluent Platform 7.2.1）
• 故障表现：test主题分区4无Leader（日志显示leader=-1），写入请求报错：

Cannot get leader of topic test partition 4: kafka server: In the middle of a leadership election, there is currently no leader for this partition and hence it is unavailable for writes

• 临时修复：提升test主题副本因子后，分区自动恢复Leader，服务恢复正常

根本原因分析 #

1. 滚动升级时出现副本全离线缺口 #

假设test分区4的两个副本分别部署在kafka-0和kafka-1上：

• 先重启kafka-0时，仅kafka-1上的副本存活，分区仍可用；
• 接着重启kafka-1时，该分区的所有副本同时离线（kafka-2上无此分区的副本）；
• Kafka的Leader选举依赖至少一个存活的同步副本（ISR），当所有副本离线时，控制器无法触发选举，分区进入无Leader状态。

2. 新旧版本控制器选举逻辑差异 #

Kafka 2.2.1到3.2.0之间，控制器的Leader选举逻辑有多处优化：

• 旧版本控制器在处理副本全离线场景时，不会主动触发选举；
• 新版本控制器重启后，可能因新旧元数据不一致，无法正确识别分区的副本存活状态，导致Leader始终无法选出。

3. 提升副本因子的修复原理 #

提升副本因子时，Kafka会自动执行以下操作：

• 控制器将新副本分配到空闲的Broker（如kafka-2）；
• 新副本完成数据同步后加入ISR列表；
• 当ISR中存在存活副本时，控制器立即触发Leader选举，选出新Leader，恢复分区可用性。

后续升级建议 #

• 升级前检查主题副本分布：确保所有主题的副本因子≤集群Broker数量，且副本均匀分布在不同Broker上，避免集中在少数节点。可通过命令kafka-topics.sh --describe --topic test --bootstrap-server <broker地址>查看副本分布。
• 控制升级节奏：每次仅重启一个Broker，等待Broker完全加入集群、ISR列表稳定后，再进行下一个节点的重启，优先重启非Leader副本所在的Broker。
• 故障应急优先方案：出现无Leader分区时，优先尝试手动触发Leader选举，命令为kafka-leader-election.sh --bootstrap-server <broker地址> --topic test --partition 4 --election-type preferred，避免直接调整副本因子带来的数据同步开销。

内容的提问来源于stack exchange，提问作者purvi ijantkar