hadoop集群搭建了ha，初次啟動正常，最近幾天啟動時偶爾發現，namenode1節點啟動后一段時間（大約10幾秒-半分鍾左右），namenode1上namenode進程停掉，查看日志：
1 2017-08-28 21:54:37,617 INFO org.apache.hadoop.ipc.Client: Retrying connect to server: slave1/192.168.128.136:8485. Already tried 9 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1000 MILLISECONDS) 2 2017-08-28 21:54:37,629 WARN org.apache.hadoop.hdfs.server.namenode.FSEditLog: Unable to determine input streams from QJM to [192.168.128.135:8485, 192.168.128.136:8485, 192.168.128.137:8485]. Skipping. 3 org.apache.hadoop.hdfs.qjournal.client.QuorumException: Got too many exceptions to achieve quorum size 2/3. 1 successful responses: 4 192.168.128.137:8485: [[1557,1558], [1559,1560], [1561,1562], [1563,1564], [1565,1566], [1567,1568], [1569,1570], [1571,1572], [1573,1574], [1575,1576], [1577,1578], [1579,1580], [1581,1582], [1583,1584], [1585,1586], [1587,1588], [1589,1589], [1590,1591]] 5 2 exceptions thrown: 6 192.168.128.136:8485: Call From master/192.168.128.135 to slave1:8485 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused 7 192.168.128.135:8485: Call From master/192.168.128.135 to master:8485 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused 8 at org.apache.hadoop.hdfs.qjournal.client.QuorumException.create(QuorumException.java:81) 9 at org.apache.hadoop.hdfs.qjournal.client.QuorumCall.rethrowException(QuorumCall.java:223) 10 at org.apache.hadoop.hdfs.qjournal.client.AsyncLoggerSet.waitForWriteQuorum(AsyncLoggerSet.java:142) 11 at org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager.selectInputStreams(QuorumJournalManager.java:471)
一、查閱資料后找到原因：
我是用start-al.sh啟動的集群，journalnode（端口8485）是在namenode后啟動的。默認情況下namenode啟動10s(maxRetries=10, sleepTime=1000)后journalnode還沒有啟動，就會報上述錯誤。
二、解決方案：
1. 修改core-site.xml中的ipc參數
1 <!--修改core-site.xml中的ipc參數,防止出現連接journalnode服務ConnectException--> 2 <property> 3 <name>ipc.client.connect.max.retries</name> 4 <value>100</value> 5 <description>Indicates the number of retries a client will make to establish a server connection.</description> 6 </property> 7 <property> 8 <name>ipc.client.connect.retry.interval</name> 9 <value>10000</value> 10 <description>Indicates the number of milliseconds a client will wait for before retrying to establish a server connection.</description> 11 </property>
注意：
1) 僅對於這種由於服務沒有啟動完成造成連接超時的問題，都可以調整core-site.xml中的ipc參數來解決。如果目標服務本身沒有啟動成功，這邊調整ipc參數是無效的。
2) 該配置使namenode連接journalnode最大時間增加至1000s(maxRetries=100, sleepTime=10000),假如集群節點數過多，或者網絡情況不穩定，造成連接時間超過1000s,仍會導致namenode掛掉。
2. 手動分步啟動 (該方式不用修改配置文件)
1 #啟動hadfs,注意有的是在多個節點執行的。 2 hadoop-daemons.sh start journalnode 3 hadoop-daemon.sh start namenode #每個namenode都要執行 4 hadoop-daemon.sh start zkfc #每個namenode都要執行 5 hadoop-daemons.sh start datanode 6 #啟動yarn 7 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