Hadoop中Namenode異常停止后無法正常啟動怎么辦

這篇文章主要講解了“Hadoop中Namenode異常停止后無法正常啟動怎么辦”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Hadoop中Namenode異常停止后無法正常啟動怎么辦”吧！

公司在線上使用了CDH5 HA模式，有兩個Namenode節點，結果其中的Standby節點因為一些關于edits文件的報錯異常停止了，并且在啟動的過程中一直報告找不到各種文件。

剛開始懷疑問題可能只發生在Standby本身，因此嘗試了bootstrapStandby來重新初始化Standby節點，但問題依舊。而后來因為我 嘗試重啟ZKFC(Zookeeper Failover)服務器，導致了Active節點進行自動切換，在切換失敗后打算切換回去時，也無法啟動服務了，報錯跟Standby節點一模一樣，于 是整個Hadoop集群就掛了。 

問題嚴重，在搜遍了整個Google都找不到任何有用的信息之后，只能求助于老大。最后，老大想到一個思路，就是將fsimage(元數據)文件與edits(編輯日志)文件都反編譯成文本，查看里面具體有什么內容，為什么加載edits文件時會報錯。

結果，這個思路給我們帶來了曙光，并最終修復了整個集群。

環境介紹：

idc2-server1: namenode, journalnode, zkfc

idc2-server2: namenode, journalnode, zkfc

idc2-server3: journalnode, resourcemanager

具體過程：

首先，是Standby Namenode上出現以下錯誤，然后自動異常關閉了進程：

2014-11-11 02:12:54,057 FATAL org.apache.hadoop.hdfs.server.namenode.ha.EditLogTailer: Unknown error encountered while tailing edits. Shutting down standby NN.
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015
       at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)
       at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:55)
...

其中提到了"Unknown error encountered while tailing edits. Shutting down standby NN."

于是，我們嘗試啟動Standby Namenode服務，結果報告以下錯誤:

2014-11-12 04:26:28,860 INFO org.apache.hadoop.hdfs.server.namenode.EditLogInputStream: Fast-forwarding stream 'http://idc2-server10.heylinux.com:8480/getJournal?jid=idc2&segmentTxId=240823073&storageInfo=-55%3A1838233660%3A0%3ACID-d77ea84b-1b24-4bc2-ad27-7d2384d222d6' to transaction ID 2407412562014-11-12 04:26:28,874 ERROR org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: Encountered exception on operation CloseOp [length=0, inodeId=0, path=/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015, replication=3, mtime=1415671845582, atime=1415670522749, blockSize=134217728, blocks=[], permissions=oozie:hdfs:rw-r--r--, aclEntries=null, clientName=, clientMachine=, opCode=OP_CLOSE, txid=240823292]
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015  at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)  at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:55)
...2014-11-12 04:26:32,641 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Encountered exception loading fsimage
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015  at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)

說找不到"/user/dong/data/dpp/classification/gender/vw-output-train /2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary /attempt_1415171013961_37060_m_000015_0/part-00015"這個文件。

而事實上，這個文件是臨時文件，不重要并且已經被刪除了。

但在上面，卻報告"ERROR org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: Encountered exception on operation CloseOp"，可以看出是在加載edits文件，執行OP_CLOSE操作時提示找不到文件。

剛開始我們懷疑可能只是Standby上的fsimage文件或edits文件有問題，于是我們在Standby上執行了 bootstrapStandby，改過程會自動從Active Namenode上獲取最新的fsimage文件，并從Journalnode日志服務器上下載并執行新的edits文件。

sudo -u hdfs hadoop namenode -bootstrapStandby

但是，在初始化之后，加載edits時仍然遇到上面相同的報錯。

而接下來，由于我嘗試將ZKFC(Zookeeper Failover)服務重啟，導致了Active Namenode自動切換到Standby，但由于Standby無法take over，所以Active Namenode切換回去的時候，也無法正常重啟了，錯誤跟Standby啟動時一樣。

這樣一來，整個Hadoop集群就掛了，在搜遍了整個Google都找不到任何有用的信息之后，我打電話給了老大，老大也通過上面的錯誤Google不到任何一條有用的信息。于是老大嘗試在edits文件中grep上面的路徑，找到了一些相關的edits文件： 

# cd /data1/dfs/nn/# cp -rpa current current.backup.orig# cd /data2/dfs/nn/# cp -rpa current current.backup.orig# cd /data1/dfs/nn/current# grep attempt_1415171013961_37060_m_000015_0 *Binary file edits_0000000000240687057-0000000000240698453 matches
Binary file edits_0000000000240823073-0000000000240838096 matches
Binary file edits_inprogress_0000000000244853266 matches

于是，我們思考能否從這些edits文件或fsimage文件中找到一些線索。

其中，關于edits文件的一些描述給我們帶來了極大的希望：

In case there is some problem with hadoop cluster and the edits file is corrupted it is possible to save at least part of the edits file that is correct. This can be done by converting the binary edits to XML, edit it manually and then convert it back to binary.

通過以上描述，我們了解到edits文件可能會corrupted，而反編譯之后手動修改，在編譯回二進制格式進行替換，可以作為一種解決辦法。于是我們將上面找到的兩個關聯edits文件，將其復制出來并進行了反編譯： 

mkdir /tmp2/
cd /data1/dfs/nn
cp edits_0000000000240687057-0000000000240698453 /tmp2/
cp edits_0000000000240823073-0000000000240838096 /tmp2/
hdfs oev -i edits_0000000000240687057-0000000000240698453 -o edits_0000000000240687057-0000000000240698453.xml
hdfs oev -i edits_0000000000240823073-0000000000240838096 -o edits_0000000000240823073-0000000000240838096.xml

反編譯之后，生成了兩個XML文件，我們在XML文件中搜索"/user/dong/data/dpp/classification/gender /vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun /_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part- 00015"，找到了OP_CLOSE與OP_DELETE相關記錄：

<RECORD>
    <OPCODE>OP_DELETE</OPCODE>
    <DATA>
      <TXID>240818498</TXID>
      <LENGTH>0</LENGTH>
      <PATH>/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015</PATH>
      <TIMESTAMP>1415671972595</TIMESTAMP>
      <RPC_CLIENTID>4a38861d-3bee-40e6-abb6-d2b58f313781</RPC_CLIENTID>
      <RPC_CALLID>676</RPC_CALLID>
    </DATA>
  </RECORD>

<RECORD>
    <OPCODE>OP_CLOSE</OPCODE>
    <DATA>
      <TXID>240823292</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>0</INODEID>
      <PATH>/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015</PATH>
      <REPLICATION>3</REPLICATION>
      <MTIME>1415671845582</MTIME>
      <ATIME>1415670522749</ATIME>
      <BLOCKSIZE>134217728</BLOCKSIZE>
      <CLIENT_NAME></CLIENT_NAME>
      <CLIENT_MACHINE></CLIENT_MACHINE>
      <PERMISSION_STATUS>
        <USERNAME>oozie</USERNAME>
        <GROUPNAME>hdfs</GROUPNAME>
        <MODE>420</MODE>
      </PERMISSION_STATUS>
    </DATA>
  </RECORD>

可以看到，對于"/user/dong/data/dpp/classification/gender/vw-output-train /2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary /attempt_1415171013961_37060_m_000015_0/part-00015"，OP_DELETE發生在了 OP_CLOSE之前，因此執行OP_CLOSE時會提示"File does not exist"。

于是，我們嘗試將OP_CLOSE這部分代碼，替換成其它的內容，比如無關痛癢的修改一個現有文件的權限，并保留TXID 240823292以確保edits文件的完整性。

<RECORD>
    <OPCODE>OP_SET_PERMISSIONS</OPCODE>
    <DATA>
      <TXID>240823292</TXID>
      <SRC>/user/oozie-heylinux/.staging/job_1415171013961_37194</SRC>
      <MODE>504</MODE>
    </DATA>
  </RECORD>

修改完成之后，再將XML文件反編譯回binary格式。

cd /tmp2/
cp edits_0000000000240823073-0000000000240838096.xml edits_0000000000240823073-0000000000240838096.xml.orig
vim edits_0000000000240823073-0000000000240838096.xml
hdfs oev -i edits_0000000000240823073-0000000000240838096.xml -o edits_0000000000240823073-0000000000240838096 -p binary

然后將binary文件同步到journalnode日志服務器中：

cd /var/hadoop/data/dfs/jn/idc2prod/
cp -rpa current current.backup.1cd /tmp2/
cp edits_0000000000240823073-0000000000240838096 /data1/dfs/nn/current/
cp edits_0000000000240823073-0000000000240838096 /data2/dfs/nn/current/
cp edits_0000000000240823073-0000000000240838096 /var/hadoop/data/dfs/jn/idc2prod/current/
scp edits_0000000000240823073-0000000000240838096 root@idc2-server2:/var/hadoop/data/dfs/jn/idc2prod/current/
scp edits_0000000000240823073-0000000000240838096 root@idc2-server3:/var/hadoop/data/dfs/jn/idc2prod/current/

然后啟動namenode服務，可以發現，之間的錯誤已經不存在了，取而代之的已經變成了其它文件。

2014-11-12 08:57:13,053 INFO org.apache.hadoop.hdfs.server.namenode.EditLogInputStream: Fast-forwarding stream 'http://idc2-server1.heylinux.com:8480/getJournal?jid=idc2prod&segmentTxId=240823073&storageInfo=-55%3A1838233660%3A0%3ACID-d77ea84b-1b24-4bc2-ad27-7d2384d222d6' to transaction ID 2402992102014-11-12 08:57:13,063 ERROR org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: Encountered exception on operation CloseOp [length=0, inodeId=0, path=/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000018_0/part-00018, replication=3, mtime=1415671845675, atime=1415670519537, blockSize=134217728, blocks=[], permissions=oozie:hdfs:rw-r--r--, aclEntries=null, clientName=, clientMachine=, opCode=OP_CLOSE, txid=240823337]
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000018_0/part-00018  at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)  at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:55)
...2014-11-12 08:57:16,847 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Encountered exception loading fsimage
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000018_0/part-00018  at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)
...

那么，接下來，就是重復以上動作，其中有時候能找到一部分規律，可以批量將同一個目錄下反復報錯的文件的OP_CLOSE都替換掉。但更多的時候則是隨機 的文件，需要一次次修改XML文件，然后編譯成binary，再啟動namenode，進行針對性的修改，一直反復的進行下去，直到Namenode能夠 成功啟動為止。

我們在具體的操作過程中，還遇到過關于OP_ADD_BLOCK的錯誤,造成問題的原因是由于最后一個edits文件在反編譯回binary文件時出現一些關于OP_UPDATE_BLOCK的錯誤。

我將報錯的部分通過以上方式進行了替換，才成功的將edits文件反編譯回binary文件。

具體的解決辦法，就是根據"Encountered exception on operation AddBlockOp"定位到OP_ADD_BLOCK相關配置并替換即可。

2014-11-12 18:07:39,070 ERROR org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: Encountered exception on operation AddBlockOp [path=/user/dong/data/dpp/classification/gender/vw-input/2014-10-30-research-with-no-confict-fix-bug-rerun/all_labelled/_temporary/1/_temporary/attempt_1415171013961_42350_m_001474_0/part-m-01474, penultimateBlock=NULL, lastBlock=blk_1109647729_35920089, RpcClientId=, RpcCallId=-2]
java.lang.IllegalStateException

最后，在Namenode啟動成功后，會報告很多Block丟失，解決辦法是通過fsck刪除這些錯誤的Block。

hadoop fsck / -files -blocks -locations | tee -a fsck.out

然后在fsck.out中獲取所有Block的信息，執行"hadoop fsck / -move"加Block進行刪除。

最后，退出safemode，生活再次變得美好起來。

hadoop dfsadmin -safemode leave"

Hadoop,Namenode

感謝各位的閱讀，以上就是“Hadoop中Namenode異常停止后無法正常啟動怎么辦”的內容了，經過本文的學習后，相信大家對Hadoop中Namenode異常停止后無法正常啟動怎么辦這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！