公司测试环境namenode修复过程

标签：dfs   mat   fsck   aec   can   为什么   解决   save   遇到   

公司测试环境的namenode出现损坏启动不了。

一开始是因为把机器的dfs目录改成了权限777，后来百度了下发现755才可以。

修改完发现namenode启动过程一直报edits文件里面存在文件丢失。

通过下面两个命令进行对edits转换成xml 修改内部不存在文件为OP_SET_PERMISSIONS操作,src随便找个hdfs存在的文件,企图跳过edits的检测,后来发现缺失文件实在太多放弃这个方式,不过这个方式缺失会跳过一些错误。

hdfs oev -i edits_0000000000015356986-0000000000015398425 -o edits_0000000000015356986-0000000000015398425.xml

hdfs oev -i edits_0000000000015356986-0000000000015398425.xml -o edits_0000000000015356986-0000000000015398425 -p binary

<RECORD>
<OPCODE>OP_SET_PERMISSIONS</OPCODE>
<DATA>
<TXID>15373436</TXID>
<SRC>/user/hue/.cloudera_manager_hive_metastore_canary/hive_HIVEMETASTORE_ec61787f31846f2121aec641cdd5fd70</SRC>
<MODE>495</MODE>
</DATA>
</RECORD>

（为什么会丢失那么多文件,我感觉是平时用hadoop fsck /检测到hdfs缺失文件过多造成hbase启动不起来，然后用了hadoop fsck -delete /清理文件造成,这个方式以后还是要小心）

到此一直没解决edits缺失文件造成namenode启动不起来问题（想过 hadoop namenode -format和 hadoop namenode -recover也还是不行因为edits缺失文件也无效），于是采用了从ha的namenode 把edits全部文件拷贝到active那个节点。（记得把原来的备份下），到此成功。

后面还遇到hbase失败，进行了wal文件夹删除和zkhbase里面的文件夹删除。重启成功（这里后面再仔细记录）

修改过程还遇到hdfs一直处于安全模式问题，但是想leave一直因为namenode挂了不能运行，这个可以在hdfs配置里面修改NameNode Default Group  修改为1就一直不会进入savemode

公司测试环境namenode修复过程

标签：dfs   mat   fsck   aec   can   为什么   解决   save   遇到   

原文地址：https://www.cnblogs.com/yaohaitao/p/12906233.html