Hadoop运维笔记 之 Namenode异常停止后无法正常启动
背景： 公司在线上使用了CDH5 HA模式，有两个Namenode节点，结果其中的Standby节点因为一些关于edits文件的报错异常停止了，并且在启动的过程中一直报告找不到各种文件。 刚开始怀疑问题可能只发生在Standby本身，因此尝试了bootstrapStandby来重新初始化Sta
背景：
公司在线上使用了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 240741256
2014-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文件中找到一些线索。
而下面的两篇文章中，提到了Hadoop自带的针对fsimage和edits文件的反编译工具：
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsImageViewer.html
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsEditsViewer.html
其中，关于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/ # cd /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.orig # cd /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 240299210
2014-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
PS: 在后来，上面的问题又再次出现了，通过分析我们发现是由于Hadoop的一个Bug导致的，从2.10-beta就开始存在了：
https://issues.apache.org/jira/browse/HDFS-6527
https://issues.apache.org/jira/browse/HDFS-6647
想要彻底避免这类问题的再次发生，必须将Hadoop升级到2.5以上版本，而对应的CDH版本则是5.2.0。
原文地址：Hadoop运维笔记 之 Namenode异常停止后无法正常启动, 感谢原作者分享。
熱AI工具
Undresser.AI Undress
人工智慧驅動的應用程序，用於創建逼真的裸體照片
AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。
Undress AI Tool
免費脫衣圖片
Clothoff.io
AI脫衣器
Video Face Swap
使用我們完全免費的人工智慧換臉工具，輕鬆在任何影片中換臉！
熱門文章
熱工具
記事本++7.3.1
好用且免費的程式碼編輯器
SublimeText3漢化版
中文版，非常好用
禪工作室 13.0.1
強大的PHP整合開發環境
Dreamweaver CS6
視覺化網頁開發工具
SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)
小紅書筆記怎麼刪除
Mar 21, 2024 pm 08:12 PM
小紅書筆記怎麼刪除?在小紅書APP中是可以編輯筆記的，多數的用戶不知道小紅書筆記如何的刪除，接下來就是小編為用戶帶來的小紅書筆記刪除方法圖文教程，有興趣的用戶快來一起看看吧！小紅書使用教學小紅書筆記怎麼刪除1、先打開小紅書APP進入到主頁面，選擇右下角【我】進入到專區;2、之後在我的專區，點擊下圖所示的筆記頁面，選擇要刪除的筆記;3、進入到筆記頁面，右上角【三個點】;4、最後下方會展開功能欄，點選【刪除】即可完成。
小紅書刪除的筆記能恢復嗎
Oct 31, 2023 pm 05:36 PM
小紅書刪除的筆記不能恢復。小紅書作為知識分享和購物平台，為使用者提供了記錄筆記和收藏有用資訊的功能。根據小紅書的官方說明，已經刪除的筆記是無法恢復的。小紅書平台並沒有提供專門的筆記恢復功能。這意味著，一旦在小紅書中刪除了筆記，無論是不小心誤刪還是其他原因，一般情況下是無法從平台上找回被刪除的內容的。如果遇到特殊情況，可以嘗試聯絡小紅書的客服團隊，看是否能夠協助解決問題。
如何在最新的iOS 17系統中連接iPhone上的Apple Notes
Sep 22, 2023 pm 05:01 PM
使用新增連結功能在iPhone上連結AppleNotes。筆記：如果您已安裝iOS17，則只能在iPhone上的AppleNotes之間建立連結。在iPhone上開啟「備忘錄」應用程式。現在，打開要在其中添加連結的註釋。您也可以選擇建立新備忘錄。點擊螢幕上的任何位置。這將向您顯示一個選單。點擊右側的箭頭以查看“新增連結”選項。點擊它。現在，您可以鍵入註解的名稱或網頁URL。然後，點擊右上角的完成，新增的連結將出現在筆記中。如果要添加指向某個單字的鏈接，只需雙擊該單字即可將其選中，選擇“添加鏈接”並按
小紅書發布過的筆記不見了怎麼辦？它剛發的筆記搜不到的原因是什麼？
Mar 21, 2024 pm 09:30 PM
作為一名小紅書的用戶，我們都曾經遇到過發布過的筆記突然不見了的情況，這無疑讓人感到困惑和擔憂。在這種情況下，我們該怎麼辦呢？本文將圍繞著「小紅書發布過的筆記不見了怎麼辦」這個主題，為你詳細解答。一、小紅書發布過的筆記不見了怎麼辦？首先，不要驚慌。如果你發現筆記不見了，保持冷靜是關鍵，不要慌張。這可能是由於平台系統故障或操作失誤引起的。檢查發布記錄很簡單。只要打開小紅書App，點擊“我”→“發布”→“所有發布”，就可以查看自己的發布記錄。在這裡，你可以輕鬆找到之前發布的筆記。 3.重新發布。如果找到了之
浪人崛起水池的異常任務攻略
Mar 26, 2024 pm 08:06 PM
水池的異常是遊戲中一個支線任務，很多玩家想知道水池的異常任務怎麼完成，其實非常簡單，首先我們要掌握在水中拍攝的技術，才可以接取任務，調查惡臭味的來源，之後發現原來是水池底下有很多的屍體，具體內容一起來看看這篇浪人崛起水池的異常任務圖文攻略。浪人崛起水池的異常任務攻略1、和飯塚對話，學習在水中拍攝的技術。 2、前往下圖位置接取水池的異常任務。 3.來到任務地點和NPC對話，了解到附近的水池有一股惡臭味。 4、前往水池調查。 5.大概游到下圖位置，潛入到水下，會發現很多的屍體。 6.使用相機對屍體進行拍攝。 7
解決Java反射異常（ReflectiveOperationException）的方法
Aug 26, 2023 am 09:55 AM
解決Java反射異常（ReflectiveOperationException）的方法在Java開發中，反射（Reflection）是一種強大的機制，它允許程式在執行時間動態地取得和操作類別、物件、方法和屬性等。透過反射，我們可以實現一些靈活的功能，例如動態創建物件、呼叫私有方法、取得類別的註解等。然而，使用反射也會帶來一些潛在的風險和問題，其中之一就是反射異常（
高效解決Java大文件讀取異常的實用技巧
Feb 21, 2024 am 10:54 AM
有效率解決Java大檔案讀取異常的實用技巧，需要具體程式碼範例概述：當處理大型檔案時，Java可能面臨記憶體溢出、效能下降等問題。本文將介紹幾種高效解決Java大檔案讀取異常的實用技巧，並提供具體程式碼範例。背景：在處理大型檔案時，我們可能需要將檔案內容讀入記憶體進行處理，例如搜尋、分析、提取等操作。然而，當檔案較大時，通常會遇到以下問題：記憶體溢位：嘗試一次性將整個文
MIT最新力作：以GPT-3.5解決時間序列異常檢測問題
Jun 08, 2024 pm 06:09 PM
今天要為大家介紹一篇MIT上週發表的文章，使用GPT-3.5-turbo解決時間序列異常檢測問題，初步驗證了LLM在時間序列異常檢測的有效性。整個過程沒有進行finetune，直接使用GPT-3.5-turbo進行異常檢測，文中的核心是如何將時間序列轉換成GPT-3.5-turbo可辨識的輸入，以及如何設計prompt或pipeline讓LLM解決異常檢測任務。下面跟大家詳細介紹一下這篇工作。圖片論文標題：Largelanguagemodelscanbezero-shotanomalydete
