WARN Fetching topic metadata with correlation id 955 for topics [Set(test3)] from broker [BrokerEndP

本文介绍了一种在使用Kafka消费消息时遇到的具体错误及其解决过程。主要问题是在尝试从指定主题读取消息时出现了ClosedChannelException异常,通过检查发现是由于集群中的一台Broker服务器开启了防火墙导致。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

生产消息

打开消费控制台查看消息命令----- ./bin/kafka-console-consumer.sh --zookeeper zk1:2181 --topic test1 --from-beginning

出现下列错误信息:


[2016-03-09 13:51:02,016] WARN Fetching topic metadata with correlation id 955 for topics [Set(test3)] from broker [BrokerEndPoint(1,brk1,9092)] failed (kafka.client.ClientUtils$)
java.nio.channels.ClosedChannelException
at kafka.network.BlockingChannel.send(BlockingChannel.scala:110)
at kafka.producer.SyncProducer.liftedTree1$1(SyncProducer.scala:75)
at kafka.producer.SyncProducer.kafka$producer$SyncProducer$$doSend(SyncProducer.scala:74)
at kafka.producer.SyncProducer.send(SyncProducer.scala:119)
at kafka.client.ClientUtils$.fetchTopicMetadata(ClientUtils.scala:59)
at kafka.client.ClientUtils$.fetchTopicMetadata(ClientUtils.scala:94)
at kafka.consumer.ConsumerFetcherManager$LeaderFinderThread.doWork(ConsumerFetcherManager.scala:66)
at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:63)



解决办法:

查看集群各个broker服务器是否打开了防火墙------/etc/rc.d/init.d/iptables status

查看结果有一台服务打开了防火墙  ,关闭   ----- /etc/rc.d/init.d/iptables stop




<think>嗯,用户遇到了Kafka的"NOT_LEADER_OR_FOLLOWER"错误,并希望找到解决方法。这个错误通常发生在生产者尝试向一个不再是Leader的分区发送消息时,可能是由于Kafka集群的Leader选举或节点故障导致的。 用户提供的引用内容很有帮助。引用[1]提到即使配置了高可靠的broker,如果生产者配置不当仍可能丢失数据。特别是当生产者使用acks=1时,如果Leader在消息复制前宕机,消息就会丢失。而当配置acks=all时,如果遇到Leader不可用的情况,生产者需要正确处理错误并重试。引用[2]说明生产者请求是由Leader broker处理的。引用[3]则提到了重启Producer可能解决某些问题。 根据这些引用和Kafka知识,我需要为用户提供系统性的解决方案。首先应该让用户检查集群状态,确认是临时故障还是持续问题。然后重点指导生产者端的配置优化,特别是重试机制和错误处理逻辑。 在解决方案中,我会建议: 1. 确保生产者配置了足够的重试次数和重试间隔 2. 设置正确的acks配置(通常推荐all) 3. 实现完善的错误处理回调 4. 监控集群健康状况 5. 考虑分区迁移或节点重启等运维操作 特别要注意引用[1]中强调的:即使broker配置可靠,生产者端的错误处理不当仍会导致数据丢失。因此解决方案会着重强调生产者重试机制的重要性。 最后会生成一些相关问题,帮助用户深入理解Kafka的可靠性机制和生产者配置的最佳实践。</think>## Kafka "NOT_LEADER_OR_FOLLOWER" 错误解决方案 这个错误表明生产者尝试向一个不再是 Leader 或 Follower 的分区发送消息。通常发生在 **集群正在进行 Leader 选举、分区迁移或 Broker 故障/重启** 期间。以下是系统性的解决方法: ### 🔧 核心解决步骤 (生产者端配置优化) 1. **启用并配置生产者重试机制** ```properties # 生产者配置示例 (Java) properties.setProperty(ProducerConfig.RETRIES_CONFIG, "2147483647"); // 最大重试次数 (Integer.MAX_VALUE) properties.setProperty(ProducerConfig.RETRY_BACKOFF_MS_CONFIG, "1000"); // 重试间隔 (毫秒) properties.setProperty(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true"); // 启用幂等性 ``` * **关键点**:重试机制是解决此错误的**核心**,允许生产者在短暂分区不可用后自动恢复[^1]。 2. **设置正确的 `acks` 配置** ```properties properties.setProperty(ProducerConfig.ACKS_CONFIG, "all"); // 确保所有ISR副本确认写入 ``` * 结合 `retries` 和 `acks=all` 可保证数据不丢失(即使遇到 Leader 切换)[^1]。 3. **实现错误处理回调** ```java producer.send(record, (metadata, exception) -> { if (exception != null) { if (exception instanceof NotLeaderOrFollowerException) { log.warn("Leader 切换中,生产者将自动重试: {}", exception.getMessage()); } else { log.error("发送失败: ", exception); } } }); ``` * 监控日志但**避免在回调中阻塞**,重试由生产者内部处理。 ### 🛠️ 集群端检查与运维 1. **检查 Broker 健康状态** ```bash # 查看 Broker 状态 bin/kafka-broker-api-versions.sh --bootstrap-server <broker_list> --describe # 检查 Controller 状态 bin/kafka-topics.sh --bootstrap-server <broker_list> --describe --topic <topic_name> --unavailable ``` * 确认所有 Broker 在线且 Controller 选举正常。 2. **分区 Leader 重新平衡** ```bash # 触发分区 Leader 均衡 bin/kafka-leader-election.sh --bootstrap-server <broker_list> --election-type PREFERRED --all-topic-partitions ``` * 修复因 Broker 宕机导致的分区无 Leader 状态。 3. **节点/服务重启** * 重启故障 Broker:`systemctl restart kafka` * **注意**:若 Producer 配置了事务,重启可能导致致命错误,需按顺序关闭[^3]。 ### 📊 预防性措施 ```mermaid graph LR A[监控] --> B[ZooKeeper 会话超时] A --> C[网络延迟] D[配置] --> E[副本因子 min.insync.replicas] D --> F[unclean.leader.election=false] ``` 1. **监控关键指标** * `UnderReplicatedPartitions`, `ActiveControllerCount`, `RequestHandlerAvgIdlePercent` * 设置告警:ZooKeeper 会话超时、网络分区。 2. **优化集群配置** ```properties # broker 端配置 unclean.leader.election.enable=false default.replication.factor=3 min.insync.replicas=2 ``` * 确保至少 2 个副本同步才允许写入 (`acks=all` 时生效)3. **分区迁移策略** * 使用 `kafka-reassign-partitions.sh` 迁移数据,避免单点过载触发频繁 Leader 选举。 > **关键结论**:此错误通常**无需人工干预**,生产者重试机制在合理配置下可自动恢复。若错误持续超过 5 分钟,需检查集群底层稳定性(网络、磁盘、ZooKeeper)[^1][^2]。 --- ### ❓相关问题 1. `acks=all` 和 `min.insync.replicas` 如何协同保证 Kafka 数据不丢失? 2. Kafka 生产者幂等性(Idempotence)是如何解决重复消息问题的? 3. 当出现持续 `NOT_LEADER_OR_FOLLOWER` 错误时,如何诊断 ZooKeeper 与 Broker 的协调问题? 4. Kafka Controller 故障转移的详细流程是怎样的? 5. 如何通过 `KafkaAdminClient` 动态监控分区 Leader 变更事件? [^1]: 生产者需配置重试和 `acks=all` 避免 Leader 切换时数据丢失 [^2]: Leader 处理生产者请求时若遇选举会返回此错误 [^3]: 事务性生产者重启需谨慎处理
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值