kafka报错LEADER_NOT_AVAILABLE

在重启后的Kafka三点集群中遇到LEADER_NOT_AVAILABLE错误,同时有ArithmeticException: / by zero的异常。经过排查,排除了Zookeeper和Kafka配置问题,通过ZK_UI工具彻底清理topic并重启服务,最终解决了问题。

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

三点集群,之前运行ok,重启后报错:

Error while fetching metadata with correlation id 10 : {yqjp-devices-sendPackage=LEADER_NOT_AVAILABLE}

伴随报错:

Caused by: java.lang.ArithmeticException: / by zero

(这个报错貌似是程序架构里面关于kafka的lib报出,

相关代码:return DefaultPartitioner.toPositive(Utils.murmur2(keyBytes)) % numPartitions;

但对应topic的partition应该为1,按理不该报错,没搞明白)


但利用脚本测试又是OK的,说明zookeeper和kafka配置应该没有问题,测试脚本参考(单节点测试,多节点同理):

kafka-topics.sh --create --zookeeper 192.168.1.22:2181 --replication-factor 2 --partitions 1 --topic HelloWorld
kafka-console-producer.sh --broker-list 192.168.1.22:9092 --topic HelloWorld

kafka-console-consumer.sh --zookeeper 192.168.1.22:2181 --from-beginning --topic HelloWorld

怀疑topic出了问题,删除报错的topic,先用如下脚本删除:

./kafka-topics.sh --delete --zookeeper 【zookeeper server】  --topic 【topic name】

但仍然报错,感觉没删除干净,只是标记为删除状态。

后来采用kafka可视化管理工具ZK_UI把里面的东西全部删除(测试环境),并重启了zookeeper和kafka,恢复正常,之前报错的topic也不报错了,ZK_UI安装参考:

https://www.ilanni.com/?p=12467

http://www.cnblogs.com/smail-bao/p/7794636.html


全程搭建无报错,感谢分享。





<think>嗯,用户想了解Kafka磁盘空间不足时的具体表现和错误信息。这个问题很实际,生产环境经常遇到。用户应该是个运维或开发人员,遇到了磁盘告急的情况。 从引用内容来看,有几个关键点需要覆盖:首先是报错的具体日志(引用1给出了完整的IO异常堆栈),其次是Kafka的默认存储策略问题(引用2提到默认保留7天且无大小限制),还有磁盘故障对集群的影响(引用3)以及客户端可能出现的异常(引用4的元数据获取错误)。 用户可能真正想知道的是:当磁盘快满时如何快速识别问题,以及如何避免服务中断。需要强调几个关键症状:1)服务端明显的"No space left"日志;2)生产者阻塞和客户端报错;3)分区停止同步。这些在回答里都用加粗突出了。 关于解决方案部分,虽然用户没直接问,但磁盘满了总得解决。结合引用2提到的retention配置优化,补充了动态调整和紧急处理建议。特别提醒了retention.bytes配置的风险,因为如果计算不当可能导致数据提前删除。 最后生成的问题延伸了应用场景(云环境)、监控工具和配置策略,这样用户可以根据实际环境深入查阅。不过有点担心第三个问题"紧急处理步骤"会不会太基础?但考虑到新手可能看到报错就慌了,保留这个基础操作提示也好。</think>当 Kafka 的磁盘空间不足时,**会报错并产生一系列影响服务的行为**。具体表现如下: 1. **Broker 日志报错 (最直接证据):** * Broker 日志中会明确出现 `java.io.IOException: No space left on device` 错误。这是磁盘空间耗尽的最直接标志。 * 错误堆栈通常与写入日志文件相关,例如在 `sinkData2Es-0` 分区(或其他分区)的日志目录(如 `/data/kafka-logs`)中尝试追加记录时失败[^1]。 * 示例关键错误信息: ```log [ERROR] Error while appending records to sinkData2Es-0 in dir /data/kafka-logs java.io.IOException: No space left on device at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at ... (后续堆栈跟踪指向 Kafka 内部的文件写入操作) ``` 2. **生产者行为异常:** * 生产者尝试向磁盘已满的 Broker 上的分区发送消息时,会收到错误响应。 * 生产者客户端会抛出异常,例如 `org.apache.kafka.common.errors.NotEnoughReplicasException` 或其子类,或者与 Broker 不可用、请求超时相关的异常(如 `TimeoutException`)。这是因为 Leader 分区无法成功写入本地日志(受磁盘空间限制),导致无法确认生产请求。 * 生产者可能会阻塞或重试,最终导致消息发送失败。 3. **分区停止工作:** * 磁盘空间不足会导致该 Broker 上所有试图写入新消息的分区(Leader 分区)不可用。这些分区无法再接受任何新的消息写入。 * 如果该分区是某个 Topic 的 Leader,其不可用会直接影响该 Topic 对应分区的生产者和消费者。 4. **副本同步失败:** * 如果此 Broker 是其他 Broker 上 Leader 分区的 Follower,它也无法从 Leader 拉取消息进行同步(因为本地没空间存储副本数据)。这会导致该分区的 ISR(In-Sync Replicas)收缩,如果所有副本都同步失败,最终可能导致分区不可用。 * 客户端(生产者和消费者)在尝试与这些受影响的分区交互时,可能会遇到 `LEADER_NOT_AVAILABLE` 或 `NOT_ENOUGH_REPLICAS` 等错误。 5. **消费者行为异常:** * 消费者尝试从位于磁盘已满 Broker 上的分区(无论是 Leader 还是 Follower)拉取消息时,可能会失败。 * 消费者客户端会收到错误,例如连接失败、请求超时、或者更具体的 `OFFSET_OUT_OF_RANGE`(如果因为空间问题触发了不期望的日志清理或损坏)、`UNKNOWN_TOPIC_OR_PARTITION` 等。错误信息中也可能包含 `Broker may not be available` 的提示[^4]。 * 消费者进度可能会停滞。 6. **Broker 可能崩溃或阻塞:** * 严重的、持续的磁盘空间不足可能导致 Broker 进程被阻塞(如日志中所示,线程在写操作上挂起)甚至崩溃退出,特别是当操作系统内核因磁盘满而强制终止进程时[^3]。 * 这会使得该 Broker 上承载的所有分区彻底不可访问,影响面扩大。 7. **集群稳定性风险:** * 单个 Broker 的磁盘满问题,如果处理不及时,可能通过副本同步失败、Leader 选举等问题扩散,最终影响整个 Kafka 集群的可用性和数据一致性[^3]。 **总结关键行为与错误信息:** * **核心错误:** Broker 日志中出现 `java.io.IOException: No space left on device`。 * **生产者表现:** 消息发送失败,客户端报错(如 `TimeoutException`, `NotEnoughReplicasException`, Broker 不可用)。 * **消费者表现:** 消息拉取失败,客户端报错(如连接失败、超时、`LEADER_NOT_AVAILABLE`, `Broker may not be available`)。 * **分区状态:** 受影响的分区停止接受写入,副本同步失败,最终可能变为不可用 (`OFFLINE`)。 * **Broker 状态:** 进程可能阻塞或崩溃,承载的所有分区不可用。 * **集群风险:** 问题可能蔓延,威胁整个集群稳定性。 **如何预防和解决:** 1. **监控与告警:** 对 Kafka Broker 的所有数据目录磁盘使用率设置严格的监控和告警阈值(如 >80% 告警)。 2. **调整保留策略:** 这是最主要的优化手段[^2]。 * `log.retention.hours`/`log.retention.minutes`: 缩短消息保留时间(如从默认 7 天改为 1-3 天)。 * `log.retention.bytes`: **设置 Topic 级别的总大小上限**(如 `retention.bytes=1073741824` 表示 1GB)。*注意:计算好业务需求,避免因空间不足导致数据被提前删除而丢失。* * `log.segment.bytes`: 调整日志段文件大小(默认 1GB),影响清理粒度。 3. **增加磁盘容量:** 最直接的解决方案,对磁盘进行扩容。 4. **数据目录隔离:** 将不同 Topic 或 Broker 的日志分配到不同的物理磁盘,避免一个磁盘故障影响全局[^3]。 5. **紧急处理:** * **首要:** 清理磁盘空间(删除无用文件、临时文件、其他应用的大日志),或立即扩容。 * **其次:** 如果清理后 Broker 未恢复,重启 Broker。 * **临时规避:** 如果某个 Topic 数据不重要且是问题根源,可临时删除其数据或缩短其保留策略。*此操作有风险。* * **Broker 下线:** 如果磁盘故障无法立即修复,需尽快将该 Broker 从集群中下线,触发副本重新选举和复制,恢复集群可用性[^3]。 **
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值