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集群管理之fsimageedits工作机制内幕详解学习笔记

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

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

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

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

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

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

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

合并过程:

 

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

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

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

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



阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/willwill101/article/details/52701517
个人分类: hadoop
上一篇使用mapreduce读取hfile
下一篇VSFTP 添加用户
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭