HDFS2.0 NameNode HA 切换失败后的恢复(元数据写坏)(2014.10.1编辑)

来源:互联网 发布:设计师有趣的事 知乎 编辑:程序博客网 时间:2024/04/30 21:13

在测试 HDFS2.0 的 NameNode HA 的时候,并发put 700M的文件,然后 Kill 主 NN ;发现备 NN 切换后进程退出。

2014-09-03 11:34:27,221 FATAL org.apache.hadoop.hdfs.server.namenode.FSEditLog: Error: recoverUnfinalizedSegments failed for required journal (JournalAndStream(mgr=QJM to [10.136.149.96:8485, 10.136.149.97:8485, 10.136.149.99:8485], stream=null))org.apache.hadoop.hdfs.qjournal.client.QuorumException: Got too many exceptions to achieve quorum size 2/3. 1 successful responses:10.136.149.99:8485: null [success]2 exceptions thrown:10.136.149.97:8485: org/apache/hadoop/io/MD5Hash

然后重启 NN 两个 NN均失败 , 

怀疑是 JN 那里有问题,可能有垃圾产生,bin/hdfs namenode -initializeSharedEdits 启动NN ,还是失败



同步两个NN的 current 元数据目录 , 重启所有 JN, 然后启动 仍然失败 ;

怀疑是 NN 对元数据的合并出了问题, 删除报错开始 的 edits 文件 ,修改 seen_txid 中的 txid 编号;

启动 NN 成功,主备NN 均启动成功。

具体原因还在定位中,但至少环境已经恢复了,最近的edits 被遗弃了。

2014.10.1 added:

原因已经定位出来:使用 stop-dfs.sh 无法停止 JN集群,更新系统包后,使用该命令停止系统后重启,实际上JN没有重启, 切换时加载新类失败异常引起。

stop-dfs.sh 通过grep关键字dfs.namenode.shared.edits.dir得到JNs,而实际上我们长会在配置中,对这个关键字增加自己到  namespace ,所以grep不到。

不过,这里到考虑,应该是多个NN共享JNs ,所以JN 不能随便重启,应该单独维护。


0 1
原创粉丝点击