Hadoop 1.x中fsimage和edits合并实现

转载 2015年11月19日 18:00:49


转自: http://www.iteblog.com/archives/969


在NameNode运行期间,HDFS的所有更新操作都是直接写到edits中,久而久之edits文件将会变得很大;虽然这对NameNode运行时候是没有什么影响的,但是我们知道当NameNode重启的时候,NameNode先将fsimage里面的所有内容映像到内存中,然后再一条一条地执行edits中的记录,当edits文件非常大的时候,会导致NameNode启动操作非常地慢,而在这段时间内HDFS系统处于安全模式,这显然不是用户要求的。能不能在NameNode运行的时候使得edits文件变小一些呢?其实是可以的,本文主要是针对Hadoop 1.x版本,说明其是怎么将edits和fsimage文件合并的,Hadoop 2.x版本edits和fsimage文件合并是不同的。
  用过Hadoop的用户应该都知道在Hadoop里面有个SecondaryNamenode进程,从名字看来大家很容易将它当作NameNode的热备进程。其实真实的情况不是这样的。SecondaryNamenode是HDFS架构中的一个组成部分,它是用来保存namenode中对HDFS metadata的信息的备份,并减少namenode重启的时间而设定的!一般都是将SecondaryNamenode单独运行在一台机器上,那么SecondaryNamenode是如何namenode重启的时间的呢?来看看SecondaryNamenode的工作情况:
  (1)、SecondaryNamenode会定期的和NameNode通信,请求其停止使用edits文件,暂时将新的写操作写到一个新的文件edit.new上来,这个操作是瞬间完成,上层写日志的函数完全感觉不到差别;
  (2)、SecondaryNamenode通过HTTP GET方式从NameNode上获取到fsimage和edits文件,并下载到本地的相应目录下;
  (3)、SecondaryNamenode将下载下来的fsimage载入到内存,然后一条一条地执行edits文件中的各项更新操作,使得内存中的fsimage保存最新;这个过程就是edits和fsimage文件合并;
  (4)、SecondaryNamenode执行完(3)操作之后,会通过post方式将新的fsimage文件发送到NameNode节点上
  (5)、NameNode将从SecondaryNamenode接收到的新的fsimage替换旧的fsimage文件,同时将edit.new替换edits文件,通过这个过程edits就变小了!整个过程的执行可以通过下面的图说明:fsimage_edits
  在(1)步骤中,我们谈到SecondaryNamenode会定期的和NameNode通信,这个是需要配置的,可以通过core-site.xml进行配置,下面是默认的配置:

1 <property>
2   <name>fs.checkpoint.period</name>
3   <value>3600</value>
4   <description>The number of seconds between two periodic checkpoints.
5   </description>
6 </property>

  其实如果当fs.checkpoint.period配置的时间还没有到期,我们也可以通过判断当前的edits大小来触发一次合并的操作,可以通过下面配置

1 <property>
2   <name>fs.checkpoint.size</name>
3   <value>67108864</value>
4   <description>The size of the current edit log (in bytes) that triggers
5        a periodic checkpoint even if the fs.checkpoint.period hasn't expired.
6   </description>
7 </property>

  当edits文件大小超过以上配置,即使fs.checkpoint.period还没到,也会进行一次合并。顺便说说SecondaryNamenode下载下来的fsimage和edits暂时存放的路径可以通过下面的属性进行配置:

01 <property>
02   <name>fs.checkpoint.dir</name>
03   <value>${hadoop.tmp.dir}/dfs/namesecondary</value>
04   <description>Determines where on the local filesystem the DFS secondary
05       name node should store the temporary images to merge.
06       If this is a comma-delimited list of directories then the image is
07       replicated in all of the directories for redundancy.
08   </description>
09 </property>
10  
11 <property>
12   <name>fs.checkpoint.edits.dir</name>
13   <value>${fs.checkpoint.dir}</value>
14   <description>Determines where on the local filesystem the DFS secondary
15       name node should store the temporary edits to merge.
16       If this is a comma-delimited list of directoires then teh edits is
17       replicated in all of the directoires for redundancy.
18       Default value is same as fs.checkpoint.dir
19   </description>
20 </property>
  从上面的描述我们可以看出,SecondaryNamenode根本就不是Namenode的一个热备,其只是将fsimage和edits合并。其拥有的fsimage不是最新的,因为在他从NameNode下载fsimage和edits文件时候,新的更新操作已经写到edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的!当然,如果NameNode中的fsimage真的出问题了,还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage,虽然已经不是最新的fsimage,但是我们可以将损失减小到最少!

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

hadoop之fsimage和edits工作机制和元数据namenode宕机恢复
  • willwill101
  • willwill101
  • 2016年09月29日 14:30
  • 1212

【总结】Hadoop文件系统元数据fsimage和编辑日志edits

原文:https://www.iteblog.com/archives/968.html   https://www.iteblog.com/archives/969.html  https://ww...
  • dengxing1234
  • dengxing1234
  • 2017年03月09日 10:18
  • 22461

【源码】Hadoop 2.x中fsimage和edits合并实现

文章来源:http://blog.csdn.net/wisgood/article/details/47066077 在《Hadoop 1.x中fsimage和edits合并实现》文章中...
  • buster2014
  • buster2014
  • 2015年07月28日 13:57
  • 235

浅谈hadoop(五)——hadoop简介 文件系统元数据的持久化

浅谈hadoop(五)——hadoop简介 本文翻译素材来自hadoop官网:http://hadoop.apache.org/docs/current/hadoop-project-dist/ha...
  • wild46cat
  • wild46cat
  • 2016年11月30日 17:33
  • 359

Hadoop深入学习:HDFS主要流程——SNN合并fsimage和编辑日志

本节我们主要写Secondary NameNode是如何合并命名空间文件和编辑日志文件。         客户端对HDFS的文件系统目录树进行的任何修改,都会被记录到编辑日志(edits)文件中,以保...
  • x_i_y_u_e
  • x_i_y_u_e
  • 2016年09月04日 10:45
  • 871

HDFS fsimage和edits合并实现原理

1. Hadoop 1.x 版本 fsimage和edits合并实现原理  在NameNode运行期间,HDFS的所有更新操作都是直接写到edits中,久而久之edits文件将会变得很大;虽然这对Na...
  • yanshu2012
  • yanshu2012
  • 2017年01月22日 17:25
  • 791

(3)hadoop学习——namenode的fsimage与editlog详解

Namenode主要维护两个文件,一个是fsimage,一个是editlog。 fsimage保存了最新的元数据检查点,包含了整个HDFS文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信...
  • chenKFKevin
  • chenKFKevin
  • 2017年03月10日 14:15
  • 2331

Hadoop FSImage文件初始结构

Namenode格式化后,会生成FSImage文件,位于dfs.name.dir参数指定目录的current目录中,记录了最初文件系统元数据的信息,随着系统运行,系统文件会越来越多,如果我们有一个要统...
  • lihm0_1
  • lihm0_1
  • 2013年08月17日 15:56
  • 1664

通过工具查看Hadoop的 fimage 文件和 edits 文件

Offline Image ViewerWeb Processorhdfs oiv -i fsimage 通过只读的 WebHDFS API 查看 fimage 所记录的文件系统信息: bash$...
  • Mark_LQ
  • Mark_LQ
  • 2016年12月12日 17:51
  • 913

hadoop edits 文件损坏修复办法

前段时间公司hadoop集群宕机,发现是namenode 磁盘满了。。清理出部分空间后,重启集群时,重启失败。 又发现集群Secondary namenode 服务也恰恰坏掉,导致所有的操作log持...
  • wisgood
  • wisgood
  • 2015年07月26日 10:40
  • 986
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Hadoop 1.x中fsimage和edits合并实现
举报原因:
原因补充:

(最多只允许输入30个字)