Kafka切换Active Controller后元数据获取失败及消息丢失问题求助

云上老周

2026-5-15

问题分析与解决思路

根据你描述的症状，大概率是Kafka控制器集群的元数据同步出了问题，或者C2节点本身的配置存在不一致的地方。咱们一步步拆解问题，定位可能的配置错误：

1. 控制器节点配置不一致是核心嫌疑

首先要确认C1和C2的server.properties（Cloudera集群里可能是通过CM管理的配置项）关键参数完全一致：

broker.id：必须保证两个节点的broker.id唯一，不能重复。
监听地址配置：listeners和advertised.listeners必须正确配置，确保其他节点和客户端能正常访问C2。如果C2的advertised.listeners配置的是错误的IP/端口，客户端（比如Streamsets、console-consumer）就无法从C2获取元数据，导致找不到分区leader。
控制器集群配置：如果是KRaft模式，检查controller.quorum.voters是否包含C1和C2的正确节点信息；如果是ZK模式，确认zookeeper.connect配置一致，且C2能正常连接ZK集群。

控制器的核心职责是管理集群元数据（比如主题、分区、leader信息），如果C2无法同步到完整的元数据，就会出现你遇到的问题：

用Kafka自带工具检查C2的元数据状态：
- KRaft模式：kafka-metadata-quorum.sh --bootstrap-server <C2_IP:9092> describe --status，查看集群的控制器状态和元数据同步情况。
- ZK模式：通过zookeeper-shell.sh <ZK集群地址>登录ZK，查看/controller节点的内容（确认C2是当前active控制器），同时检查/brokers/topics/testD下的元数据是否存在。
查看C2的Kafka日志，搜索是否有Controller failed to become active、Metadata sync failed这类报错，这些信息能直接定位元数据同步失败的原因。

当C2成为Active Controller后出现每两条丢一条的情况，说明部分分区的Leader没有被正确识别或切换：

执行kafka-topics.sh --describe --topic testD --bootstrap-server <C2_IP:9092>，查看每个分区的Leader和ISR列表：
- 如果某个分区的Leader是已下线的C1（broker.id对应C1），说明C2没有触发该分区的Leader选举。
- 检查min.insync.replicas配置，如果该值设置过高（比如等于2），当C1下线后，部分分区的ISR列表不满足min.insync.replicas要求，导致生产者发送的消息无法被确认，或者消费者无法读取。
确认auto.leader.rebalance.enable是否开启（默认是开启的），以及leader.imbalance.check.interval.seconds的配置，确保控制器切换后能自动重新平衡Leader。必要时可以手动触发Leader选举：
```
kafka-leader-election.sh --bootstrap-server <C2_IP:9092> --topic testD --election-type preferred
```

你提到关闭C1后，Streamsets和console-consumer都无法获取元数据，看报错里的BrokerEndPoint(183,110.250.17.242,9092)，这个大概率是C1的地址：

检查客户端（Streamsets、kafka-console-consumer）的bootstrap.servers配置，是否只填了C1的地址？如果是，当C1下线后，客户端就无法连接到集群获取元数据了。
正确的做法是把**所有Broker/控制器节点的地址都加到bootstrap.servers**里，比如C1_IP:9092,C2_IP:9092，这样客户端可以自动发现可用的节点，获取最新的元数据。

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