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 搭載アプリ
AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。
Undress AI Tool
脱衣画像を無料で
Clothoff.io
AI衣類リムーバー
AI Hentai Generator
AIヘンタイを無料で生成します。
人気の記事
ホットツール
メモ帳++7.3.1
使いやすく無料のコードエディター
SublimeText3 中国語版
中国語版、とても使いやすい
ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境
ドリームウィーバー CS6
ビジュアル Web 開発ツール
SublimeText3 Mac版
神レベルのコード編集ソフト（SublimeText3）
ホットトピック
7473
15
1377
52
77
11
19
31
小紅書メモを削除する方法
Mar 21, 2024 pm 08:12 PM
小紅書メモを削除するにはどうすればよいですか? メモは小紅書アプリで編集できます。ほとんどのユーザーは小紅書メモの削除方法を知りません。次に、エディターがユーザーに小紅書メモの削除方法に関する写真とテキストを提供します。チュートリアル、興味のあるユーザーが来て、それを受講してください見てください！小紅書使い方チュートリアル 小紅書メモの削除方法 1. まず小紅書アプリを開いてメインページに入り、右下隅の[自分]を選択して特別エリアに入ります; 2. 次に、マイエリアで、表示されているメモページをクリックします下の図で、削除したいメモを選択します; 3. メモページに入り、右上隅の [3 つの点] をクリックします; 4. 最後に、下部に機能バーが展開され、[削除] をクリックして完了します。
小紅書に関する削除されたメモは復元できますか?
Oct 31, 2023 pm 05:36 PM
小紅書から削除されたメモは復元できません。小紅書は知識共有とショッピングのプラットフォームとして、ユーザーにメモを記録し、役立つ情報を収集する機能を提供します。小紅書氏の公式声明によると、削除されたメモは復元できないとのこと。小紅書プラットフォームには、専用のノート回復機能はありません。これは、Xiaohongshu でメモが削除されると、誤って削除されたか、その他の理由であったとしても、プラットフォームから削除されたコンテンツを取得することは通常不可能であることを意味します。特別な状況が発生した場合は、Xiaohongshu のカスタマー サービス チームに連絡して、問題の解決に協力できるかどうかを確認してください。
小紅書に投稿したメモが見つからない場合はどうすればよいですか?送信したばかりのメモが見つからない理由は何ですか?
Mar 21, 2024 pm 09:30 PM
小紅書のユーザーとして、私たちは皆、公開されたノートが突然消えてしまう状況に遭遇したことがありますが、間違いなく混乱し、心配しています。この場合、どうすればよいでしょうか？この記事では、「小紅書が公開したメモが見つからない場合の対処方法」というテーマに焦点を当て、詳細な回答を提供します。 1. 小紅書が発行したメモが紛失した場合はどうすればよいですか?まず、パニックにならないでください。メモがなくなっていることに気づいた場合は、パニックに陥らず、落ち着いて行動することが重要です。これは、プラットフォームのシステム障害または操作エラーが原因である可能性があります。リリース記録の確認も簡単です。小紅書アプリを開き、「自分」→「公開」→「すべての出版物」をクリックするだけで、自分の出版記録を表示できます。ここでは、以前に公開されたノートを簡単に見つけることができます。 3.再投稿。見つかったら
最新のiOS 17システムでiPhoneにApple Notesを接続する方法
Sep 22, 2023 pm 05:01 PM
リンクの追加機能を使用して iPhone で AppleNotes をリンクします。注: iOS17 がインストールされている場合、iPhone 上で Apple Notes 間のリンクを作成することができます。 iPhone でメモ アプリを開きます。次に、リンクを追加するメモを開きます。新しいメモを作成することもできます。画面上の任意の場所をクリックします。メニューが表示されます。右側の矢印をクリックして、「リンクの追加」オプションを表示します。クリックして。ここで、メモの名前または Web ページの URL を入力できます。次に、右上隅の「完了」をクリックすると、追加されたリンクがメモに表示されます。単語にリンクを追加したい場合は、単語をダブルクリックして選択し、「リンクを追加」を選択して、 を押します。
Java リフレクション例外 (ReflectiveOperationException) を解決するメソッド
Aug 26, 2023 am 09:55 AM
Java リフレクション例外 (ReflectiveOperationException) を解決するメソッド Java 開発において、リフレクション (Reflection) は、プログラムが実行時にクラス、オブジェクト、メソッド、プロパティなどを動的に取得して操作できるようにする強力なメカニズムです。リフレクションを通じて、オブジェクトの動的作成、プライベート メソッドの呼び出し、クラス アノテーションの取得など、いくつかの柔軟な機能を実装できます。ただし、リフレクションの使用には、いくつかの潜在的なリスクと問題も伴います。その 1 つは、リフレクションの異常です (
小紅書でノートに商品リンクを追加する方法 小紅書でノートに商品リンクを追加するチュートリアル
Mar 12, 2024 am 10:40 AM
小紅書でメモに商品リンクを追加するにはどうすればよいですか?小紅書アプリでは、ユーザーはさまざまなコンテンツを閲覧できるだけでなく、ショッピングもできるため、このアプリにはショッピングのおすすめや良い商品の共有に関するコンテンツがたくさんあります。このアプリでは、ショッピング体験を共有したり、協力してくれる販売者を見つけたり、メモにリンクを追加したりすることもできます。便利なだけでなく、専門家がいくつかの機能を備えているため、多くの人がこのアプリをショッピングに使用したいと考えています。興味深いコンテンツを閲覧して、自分に合った衣料品があるかどうかを確認できます。ノートに商品リンクを追加する方法を見てみましょう! 小紅書ノートに商品リンクを追加する方法 携帯電話のデスクトップでアプリを開きます。アプリのホームページをクリックします
Rise of Ronin プールの珍しいミッションのガイド
Mar 26, 2024 pm 08:06 PM
プールの異常はゲームのサイド タスクです。多くのプレイヤーは、プールの異常のタスクを完了する方法を知りたがっています。実際には非常に簡単です。まず、受け入れる前に、水中での射撃のテクニックを習得する必要があります。タスクを実行し、悪臭の原因を調査します。後で、プールの下にたくさんの死体があることがわかりました。Rise of Ronin のプールでの珍しいタスクについてのこのグラフィック ガイドを見てみましょう。 Ronin Rise プールでの珍しいミッションのガイド: 1. 飯塚と話し、水中での射撃のテクニックを学びます。 2. 以下の図の場所に移動し、プール内の異常タスクを受け取ります。 3. ミッションの場所に行き、NPCに話しかけると、近くのプールで異臭が発生していることを知ります。 4. プールに行って調査します。 5.下の写真の場所まで泳いで水中に潜ると、大量の死体が見つかります。 6. カメラを使って死体の写真を撮ります。 7
MIT の最新傑作: GPT-3.5 を使用して時系列異常検出の問題を解決する
Jun 08, 2024 pm 06:09 PM
今日は、MIT が先週公開した記事を紹介します。GPT-3.5-turbo を使用して時系列異常検出の問題を解決し、時系列異常検出における LLM の有効性を最初に検証しました。プロセス全体に微調整はなく、GPT-3.5-turbo は異常検出に直接使用されます。この記事の核心は、時系列を GPT-3.5-turbo が認識できる入力に変換する方法とその設計方法です。 LLM が異常検出タスクを解決できるようにするためのプロンプトまたはパイプライン。この作品について詳しく紹介していきます。画像用紙タイトル：Large languagemodelscanbeゼロショタノマリデテ
