hadoop中edits文件损坏如何修复

这篇文章将为大家详细讲解有关hadoop中edits文件损坏如何修复，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

10年的牧野网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都营销网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整牧野建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联公司从事“牧野网站设计”,“牧野网站推广”以来，每个客户项目都认真落实执行。

      前段时间公司hadoop集群宕机，发现是namenode 磁盘满了。。清理出部分空间后，重启集群时，重启失败。

又发现集群Secondary namenode 服务也恰恰坏掉，导致所有的操作log持续写入edits.new 文件，等集群宕机的时候文件大小已经达到了丧心病狂的70G+..重启集群报错 加载edits文件失败。分析加载文件报错原因是磁盘不足导致最后写入的log只写入一半就宕机了。由于log不完整，hadoop再次启动加载edits文件时读取文件报错。由于edits.new 文件过大，存储了好多操作log，所以必须要对其进行修复。

        尝试删除文件的最后几行，结果还是报错。于是查看源码对edits 文件结构进行分析发现是二进制格式，首行为版本号，然后是hadoop运行过程中的log记录内容，由操作码 +长度(非必须)+其他项组成。

edits文件格式分析图

解决办法

报错位置在源码中的方法为org.apache.hadoop.hdfs.server.namenode.FSEditLog.loadFSEdits(EditLogInputStream edits)方法中读取文件最后位置时因为缺少部分数据报错， 所以把这部分代码单独拿出来，去掉业务操作部分，只留读取过程，记录异常之前的文件长度len，然后将0到len 这部分的内容复制出来成新的edits文件。启动hadoop集群，成功！

NameNode启动加载元数据情景分析

• NameNode函数里调用FSNamesystemm读取dfs.namenode.name.dir和dfs.namenode.edits.dir构建FSDirectory。

• FSImage类recoverTransitionRead和saveNameSpace分别实现了元数据的检查、加载、内存合并和元数据的持久化存储。

• saveNameSpace将元数据写入到磁盘，具体操作步骤：首先将current目录重命名为lastcheckpoint.tmp;然后在创建新的current目录，并保存文件；最后将lastcheckpoint.tmp重命名为privios.checkpoint.

• checkPoint的过程：Secondary NameNode会通知nameNode产生一个edit log文件edits.new，之后所有的日志操作写入到edits.new文件中。接下来Secondary NameNode会从namenode下载fsimage和edits文件，进行合并产生新的fsimage.ckpt;然后Secondary会将fsimage.ckpt文件上传到namenode。最后namenode会重命名fsimage.ckpt为fsimage，edtis.new为edits；

    PS：

最新的CDH版本的hadoop 集群启动可以对edits文件进行recover操作，跳过报错log

关于“hadoop中edits文件损坏如何修复”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。

当前标题：hadoop中edits文件损坏如何修复
分享网址：http://cdiso.cn/article/jgcjdi.html