錯誤記錄與分析
錯誤1：java.net.BindException: Port in use: localhost:0
datanode節點啟動時報錯 日志信息如下： Exiting with status 1: java.net.BindException: Port in use: localhost:0 解決：在/etc/hosts文件開頭添加如下內容 ::1 localhost 127.0.0.1 localhost
錯誤2：datanode節點磁盤空間爆滿，導致datanode啟動不能啟動
解決: 1、查看數據 hadoop fs -du -h /user/data/hadoop 2、刪除最舊的數據 hadoop fs -rm -r -skipTrash /user/hadoop/data/2018-11* 刪除一個月的 注：這里只是舉一個樣例，當空間不足的時候，就刪掉某一數據。但是，通常情況下，在配置部署集群的時候，都會配置磁盤預留10%的容量。 還有一種情況：當某一塊磁盤容量100%的時候，datanode節點不能啟動。這種解決方法就是刪除這塊磁盤下的某些不重要的數據，比如日志文件。刪除以后可以正常啟動，接着執行balancer就可以。
錯誤3：java.io.IOException: Premature EOF from inputStream
報錯信息如下： 2019-03-08 09:54:12,046 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Exception for BP-2086716179-x.x.x.x-1547613222606:blk_1100079604_26351635 java.io.IOException: Premature EOF from inputStream 從錯誤來看，是由於文件被提前關閉，導致io錯誤。發生這種情況通常是在客戶端讀寫hdfs上的文件時發生的。 解決： 1、修改hdfs-site.xml（每個節點都要改）： dfs.datanode.max.transfer.threads 值修改為8192。這個是datanode同時處理請求的任務上限，總默認值是 4096，該參數取值范圍[1 to 8192]。 2、修改操作系統打開文件數。
當然也有可能是其他問題導致的。
錯誤4：org.apache.hadoop.net.ConnectTimeoutException: 60000 millis timeout while waiting for channel to be ready for connect
k_1087564514_13888513 received exception org.apache.hadoop.net.ConnectTimeoutException: 60000 millis timeout while waiting for channel to be ready for connect. ch : java.nio.channels.SocketChannel[connection-pending remote=/58.240.56.125:50010] 19/03/11 18:14:44 WARN balancer.Dispatcher: Failed to move blk_1087564434_13888433 with size=40766000 from x.x.x.x:50010:DISK to y.y.y.y:50010:DISK through x.x.x.x:50010: block move is failed: opReplaceBlock BP-1866268144-x.x.x.x-1464939869265:blk_1087564434_13888433 received exception org.apache.hadoop.net.ConnectTimeoutException: 60000 millis timeout while waiting for channel to be ready for connect. ch : java.nio.channels.SocketChannel[connection-pending remote=/x.x.x.x:50010] hadoop客戶端連接超時問題 解決 修改hdfs-site.xml文件，添加 hdfs客戶端的讀寫超時時間 dfs.client.socket-timeout(默認60000) dfs.datanode.socket.write.timeout(默認80000) dfs.datanode.handler.count=50
錯誤5：All datanodes 58.240.56.122:50010 are bad. Aborting.
這個問題的原因不確定，可能會有多種情況導致。
1、查看當前系統的最大打開文件數量是否受限制；ulimt -n。
我這邊系統的最大文件數量已經被設置為65535，但依然在hbase的日志里面大量的報這個錯誤。最后發現是由於datanode服務器壓力過大導致，最后通過調整hbase的regionserver的heap大小降低服務器的壓力。(一共兩台datanode 0.0)
可能還要其他原因導致，這邊暫時沒有分析出來，期待以后補上了。
錯誤5：AttemptID:attempt_1547604600777_0101_r_000085_0 Timed out after 600 secs 或者 Too Many fetch failures.Failing the attempt
reduce任務失敗，最終導致整個作業失敗。 問題分析：這個是由於某個reduce任務重試4次后，job失敗，原因就是因為超時。mapreduce.task.timeout參數對應的超時時間是600s。這意味着，如果map或reduce方法在600秒內沒有返回或者輸出內容， NM將認為相應的map或reduce已經死亡。 並向AM匯報錯誤。AM會殺死此次嘗試，並在其他節點上重新執行它。 可能導致的原因： (1)、跑reduce任務的datanode節點壓力大，可以使用top、iostart、sar等命令查看系統資源使用情況。也有可能datanode掛掉。 (2)、網絡問題，網絡IO過大。 (3)、程序死循環。
(4)、數據傾斜。 解決： 檢查網絡問題、datanode節點是否資源不足。
錯誤6：java.io.IOException: Broken pipe
原因分析 (1).當訪問某個服務突然服務器掛了，就會產生Broken pipe; (2).客戶端讀取超時關閉了連接，這時服務器往客戶端再寫數據就發生了broken pipe異常！
錯誤7：java.net.SocketTimeoutException: 60000 millis timeout while waiting for channel to be ready for read. ch
解決：打開core-site.xml文件 添加：ipc.ping.interval=180000
錯誤8：ssh連接問題：shell request failed on channel 0
分析：操作系統進程數量太小，導致連接失敗
解決：修改操作系統最大進程數量
ulimit -u 查看最大進程數量。
錯誤9：The accepted epoch, d is less than the current epoch, 5e4
zookeeper啟動報錯
解決：進入到zookeeper數據目錄下的version-2目錄，把acceptedEpoch文件里面的值改成currentEpoch里面的值，也就是上述的5e4.
錯誤10：namenode報錯，the directory item limit is exceed: limit=1048576
調整hadoop單個目錄下的文件數量： namenode日志里面可能存在如下錯誤： the directory item limit is exceed: limit=1048576 hadoop單個目錄下文件超1048576個，默認limit限制數為1048576，所以要調大limit限制數 調整： 參數：dfs.namenode.fs-limits.max-directory-items 值：3200000 注：值范圍 1 ~ 6400000 將配置文件推送至hadoop集群所有節點 重啟hadoop服務
錯誤11：journalnode報錯，org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager: Waited 96275 ms (timeout=20000 ms) for a response for sendEdits. No responses yet.
調節journalnode 的寫入超時時間，默認20000(20s) namenode日志文件可能存在的錯誤： org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager: Waited 96275 ms (timeout=20000 ms) for a response for sendEdits. No responses yet. 參數：dfs.qjournal.write-txns.timeout.ms 值：200000(200s)
錯誤12：java.io.IOException: Can't scan a pre-transactional edit log.
由於數據磁盤爆滿，達到100%，導致journalnode宕掉，在啟動journalnode以后，查看日志，提示Can't scan a pre-transactional edit log，這個時候namenode已經是不能正常啟動了。 java.io.IOException: Can't scan a pre-transactional edit log. at org.apache.hadoop.hdfs.server.namenode.FSEditLogOp$LegacyReader.scanOp(FSEditLogOp.java:4974) at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanNextOp(EditLogFileInputStream.java:245) at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanEditLog(EditLogFileInputStream.java:355) at org.apache.hadoop.hdfs.server.namenode.FileJournalManager$EditLogFile.scanLog(FileJournalManager.java:551) at org.apache.hadoop.hdfs.qjournal.server.Journal.scanStorageForLatestEdits(Journal.java:192) at org.apache.hadoop.hdfs.qjournal.server.Journal.<init>(Journal.java:152) at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:90) at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:99) at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.getEditLogManifest(JournalNodeRpcServer.java:189) at 解決辦法： 1、刪除數據磁盤的一些無用的數據，讓磁盤有一定的空間，只要空間>0k,journalnode就可以正常啟動，我這邊就是某一塊盤一點磁盤空間都沒有，可用空間0k。導致在啟動journalnode的時候提示磁盤空間不足，說到底，還是集群在規划的時候沒有預留磁盤空間導致的，給差評。 2、報上述的 Can't scan a pre-transactional edit log 錯誤，就是由於journalnode維護的eidts文件損壞，這個時候，看一下journalnode幾台節點，哪一台是好的，先刪除損壞的journalnode的數據文件，然后把這台好的journalnode文件拷貝到其他的節點。 3、修改拷貝過來的數據文件的權限 4、重啟journalnode。
分析：由於在生產環境下，ssh的端口被修改成220，不是使用的默認端口，但是hadoop在啟動相應進程的時候，使用的ssh默認端口 解決： 1、命令行(臨時)，這種方式會導致關閉當前終端，該值失效。 export HADOOP_SSH_OPTS="-p 220" 2、永久修改：把上述的命令添加到hadoop的hadoop-env.sh文件，添加以后就可以正常啟動hadoop進程。
錯誤14：Unable to fence NameNode at master/172.17.0.11:8020
解決： 提示未找到fuster程序，導致無法進行fence，所以可以通過如下命令來安裝，Psmisc軟件包中包含了fuster程序 #apt-get update # apt-get install psmisc