Call From master/192.168.128.135 to master:8485 failed on connection exception: java.net.ConnectException: Connection refused

时间:2021-06-16 21:09:19

hadoop集群搭建了ha,初次启动正常,最近几天启动时偶尔发现,namenode1节点启动后一段时间(大约10几秒-半分钟左右),namenode1上namenode进程停掉,查看日志:

 -- ::, INFO org.apache.hadoop.ipc.Client: Retrying connect to server: slave1/192.168.128.136:. Already tried  time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=, sleepTime= MILLISECONDS)
-- ::, WARN org.apache.hadoop.hdfs.server.namenode.FSEditLog: Unable to determine input streams from QJM to [192.168.128.135:, 192.168.128.136:, 192.168.128.137:]. Skipping.
org.apache.hadoop.hdfs.qjournal.client.QuorumException: Got too many exceptions to achieve quorum size /. successful responses:
192.168.128.137:: [[,], [,], [,], [,], [,], [,], [,], [,], [,], [,], [,], [,], [,], [,], [,], [,], [,], [,]]
exceptions thrown:
192.168.128.136:: Call From master/192.168.128.135 to slave1: failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused
192.168.128.135:: Call From master/192.168.128.135 to master: failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused
at org.apache.hadoop.hdfs.qjournal.client.QuorumException.create(QuorumException.java:)
at org.apache.hadoop.hdfs.qjournal.client.QuorumCall.rethrowException(QuorumCall.java:)
at org.apache.hadoop.hdfs.qjournal.client.AsyncLoggerSet.waitForWriteQuorum(AsyncLoggerSet.java:)
at org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager.selectInputStreams(QuorumJournalManager.java:)

一、查阅资料后找到原因:

我是用start-al.sh启动的集群,journalnode(端口8485)是在namenode后启动的。默认情况下namenode启动10s(maxRetries=10, sleepTime=1000)后journalnode还没有启动,就会报上述错误。

二、解决方案:

1.  修改core-site.xml中的ipc参数

 <!--修改core-site.xml中的ipc参数,防止出现连接journalnode服务ConnectException-->
<property>
<name>ipc.client.connect.max.retries</name>
<value>100</value>
<description>Indicates the number of retries a client will make to establish a server connection.</description>
</property>
<property>
<name>ipc.client.connect.retry.interval</name>
<value>10000</value>
<description>Indicates the number of milliseconds a client will wait for before retrying to establish a server connection.</description>
</property>

注意:

  1) 仅对于这种由于服务没有启动完成造成连接超时的问题,都可以调整core-site.xml中的ipc参数来解决。如果目标服务本身没有启动成功,这边调整ipc参数是无效的。

  2) 该配置使namenode连接journalnode最大时间增加至1000s(maxRetries=100, sleepTime=10000),假如集群节点数过多,或者网络情况不稳定,造成连接时间超过1000s,仍会导致namenode挂掉。

2.  手动分步启动  (该方式不用修改配置文件)

 #启动hadfs,注意有的是在多个节点执行的。
hadoop-daemons.sh start journalnode
hadoop-daemon.sh start namenode #每个namenode都要执行
hadoop-daemon.sh start zkfc #每个namenode都要执行
hadoop-daemons.sh start datanode
#启动yarn
start-yarn.sh

分步启动集群的方式,因为journalnode是在namenode之前启动的,所以正常情况下一次就会连接成功,不会重试多次。

3.  先启动ha集群,报错后再单独启动namenode (该方式不用修改配置文件)

start-all.sh #启动ha集群

启动后等待一会,jps确认没有namenode,再重新单独启动namenode

hadoop-daemon.sh start namenode  #挂掉的namenode节点执行

PS: 该方式减少了输入量,又解决了异常。虽然是一种不够优雅的解决方式,但确是懒人的福音。

三、错误再次分析

  由于部署好ha后,首次启动我是分步启动的,没有遇到该问题。之后都是start-all.sh启动,大约70%情况下会有该问题,30%左右的启动是正常的,究其原因,我想70%的时候journalnode启动比较慢,另有个别时候是启动比较快。实测中确实发现集群主机刚刚开机,就启动hadoop,会比较慢;等一段时间再启动或者首次启动hadoop后停止,然后再重新启动,这两种情况下hadoop启动会比较快。我是虚拟机,通常会第一时间启动hadoop,所以遇到这个坑的时候比较多。当然,找到了根本原因,无论hadoop启动快慢namenode都不会挂掉了。

  另外namenode启动后有退出有多种原因,本文只针对启动的一种,具体情况需要查看日志并寻找合适解决方案。

致谢:http://www.linuxidc.com/Linux/2016-03/129437.htm