java.io.IOException: Connection to 2 was disconnected before the response was read
at org.apache.kafka.clients.NetworkClientUtils.sendAndReceive(NetworkClientUtils.java:93)
at kafka.server.ReplicaFetcherBlockingSend.sendRequest(ReplicaFetcherBlockingSend.scala:93)
at kafka.server.ReplicaFetcherThread.fetch(ReplicaFetcherThread.scala:207)
at kafka.server.ReplicaFetcherThread.fetch(ReplicaFetcherThread.scala:42)
at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:151)
at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:112)
at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:64)
解决过程:
brokerf 0 , 1 两台服务器连续报了 6 天时间,决定查清楚到底是什么原因导致
a 使用 du -h -d 1 这条命令查看 kafka-log 这个目录有多大 ,
broker 0 50M
broker 1 50M
broker 2 100M
b 一直报 connection 异常 , 所以 使用 tcpdump + wireshark 对 9092 端口抓包分析 , 发现有好多是 网络重试的,把 kafka 在zk /brokers/ids/0 中的外网地址改成内网地址,问题仍然未解决。(是不能改的,因为外网关闭与kafka连接时会报异常)
c 尝试使用 topic 迁移 , 发现可以进行数据迁移 , 但是问题仍然未解决。
c 根据分析,发现 broker 2 节点一直在 Shrinking , 所以尝试把 controller 通过关闭broker 0 , 1 转移到 broker2 上来。最终把该问题解决掉了。
d 使用 c 步骤,需要小心引起集群的 rebalance 问题。
本文记录了一次Kafka集群中出现的网络异常问题排查与解决方案,详细描述了从初步观察到问题定位,再到最终解决的全过程。通过检查日志、磁盘使用情况、网络抓包分析及调整配置等手段,最终将问题归因于Broker节点状态不稳定,并通过转移Controller角色成功解决问题。
2011

被折叠的 条评论
为什么被折叠?



