hadoop之fsimage和edits工作机制和元数据namenode宕机恢复

今天发现我们的集群namenode启动不了了，报错如下图

关键在于在secondarynamenode报错停止之后，namenode开始创建edits.new文件记录新的操作元数据，然后不知道是由于什么问题导致的这个元数据加载报错。

按照网上的一下资料恢复了集群，但是丢失了n多数据

4.恢复 
制造namenode宕机的情况 
1) kill 掉namenode的进程 



Java代码  
1. [root @master  name]# jps    
2. 11749  NameNode    
3. 12339  Jps    
4. 11905  JobTracker    
5. [root@master  name]# kill  11749     



 2)删除dfs.name.dir所指向的文件夹，这里是/data/work/hdfs/name 



Java代码  
1. [root @master  name]# rm -rf *    


   删除name目录下的所有内容，但是必须保证name这个目录是存在的 

3）从secondarynamenode远程拷贝namesecondary文件到namenode的namesecondary 



Java代码  
1. [root @master  hdfs]# scp -r slave- 001 :/data/work/hdfs/namesecondary/ ./    



 4）启动namenode 



Java代码  
1. [root @master  /data]# hadoop namenode –importCheckpoint    


正常启动以后，屏幕上会显示很多log，这个时候namenode就可以正常访问了 

5)检查 
使用hadoop fsck /user命令检查文件Block的完整性 

6）停止namenode，使用crrl+C或者会话结束 

7）删除namesecondary目录下的文件（保存干净） 



Java代码  
1. [root @master  namesecondary]# rm -rf *    



 8）正式启动namenode 



Java代码  
1. [root @master  bin]# ./hadoop-daemon.sh  start namenode    



恢复工作完成，检查hdfs的数据 

 还有一个将edits的工作原理的，这里也记录一下

Hadoop集群管理之fsimage和edits工作机制内幕详解学习笔记

客户端对hdfs进行写文件时会首先被记录在edits文件中。

edits修改时元数据也会更新。

每次hdfs更新时edits先更新后客户端才会看到最新信息。

fsimage:是namenode中关于元数据的镜像，一般称为检查点。

一般开始时对namenode的操作都放在edits中，为什么不放在fsimage中呢？

因为fsimage是namenode的完整的镜像，内容很大，如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。

内容包含了namenode管理下的所有datanode中文件及文件block及block所在的datanode的元数据信息。随着edits内容增大，就需要在一定时间点和fsimage合并。

合并过程：

 

完成合并的是secondarynamenode，会请求namenode停止使用edits,暂时将新写操作放入一个新的文件中（edits.new)。secondarynamenode从namenode中通过http get获得edits，因为要和fsimage合并，所以也是通过http get 的方式把fsimage加载到内存，然后逐一执行具体对文件系统的操作，与fsimage合并，生成新的fsimage，然后把fsimage发送给namenode，通过http post的方式。namenode从secondarynamenode获得了fsimage后会把原有的fsimage替换为新的fsimage,把edits.new变成edits。同时会更新fstime。

hadoop进入安全模式时需要管理员使用dfsadmin的save namespace来创建新的检查点。

secondarynamenode在合并edits和fsimage时需要消耗的内存和namenode差不多，所以一般把namenode和secondarynamenode放在不同的机器上。

fs.checkpoint.period: 默认是一个小时（3600s)

fs.checkpoint.size:  edits达到一定大小时也会触发合并（默认64MB)

 

还有哥们说有一个解决方案，但是没能实现，等下次再搞吧记录一下

解决办法

报错位置在源码中的方法为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