HDFS之fsimage、metadata、edits、fstime

 首先,要有这个观念,元数据信息(fsimage + editslog)。

 

    fsimage是在磁盘

    metadata是在内存

    ********************fsimage把内存的,序列化到磁盘了。********************

    元数据信息(fsimage + editslog),内存保存一份,磁盘保存一份,,,,,其他有个什么地方也要保存一份。

  ==============》 就如,学校图书馆里。书库,为了使得借书运转,要买多本书存库。《======================

   

    fsimage:元数据镜像文件,存储某一时段NameNode内存元数据信息。

        在hadoop1.*里,就是fsimage。

        在hadoop2.*里,还加了后缀。

        听说过镜像。  关闭时,将机器内存的信息写到磁盘,启动时,将磁盘的东西读取到内存。

   edits:操作日志文件

        比如说,上传一个文件或删除一个文件,这些操作。

   fstime:保存最近一次checkpoint的时间     

        比如说,在6月1号买的新电脑,在6月5日,做的第一次还原点,在6月18号,由于中病毒。在6月21号是做的第二次还原点。Checkpoint是保存最近的那次做还原点的数据。6月18-21日。

  namenode始终在内存中保存metadata,用于处理“读请求”。到有“读请求”时,namenode会首先写editlog到磁盘,即向edits(操作日志文件)中写入日志,成功返回后,才会修改内存,并且向客户端返回。

  形象化例子:我client提货员,向仓库管理员namenode,请求提货,在他同意同时,会将这情况写到editlog,先是将editlog写到磁盘,成功后,再写到内存。

  

fsimage载入内存     合并edits

    |

     |

     |

新的 fsimage  

          |

     |

     |

namenode,替换旧的

条件一:

fs.checkpoint.period

默认是3600秒,每隔一个小时,Secondarynamenode就要下载fsimage和edits,进行数据的同步。

条件二:

fs.checkpoint.size

edits一直在变大。一旦达到,就要进行合并。

只要达到这两个条件的其中一个,都会进行合并。

时间: 2024-10-14 11:36:55

HDFS之fsimage、metadata、edits、fstime的相关文章

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

客户端对hdfs进行写文件时会首先被记录在edits文件中. edits修改时元数据也会更新. 每次hdfs更新时edits先更新后客户端才会看到最新信息. fsimage:是namenode中关于元数据的镜像,一般称为检查点. 一般开始时对namenode的操作都放在edits中,为什么不放在fsimage中呢? 因为fsimage是namenode的完整的镜像,内容很大,如果每次都加载到内存的话生成树状拓扑结构,这是非常耗内存和CPU. 内容包含了namenode管理下的所有datanode

fsimage metadata

想说的是,fsimage 是在磁盘.metadata是在内存. 元数据metadata,内存保存一份,磁盘保存一份. 备份机制思想,就如同在学校图书馆中的书库.为了使得借书运转,要买多本书存库. 我client提货员,向仓库管理员namenode,请求提货,在他同意同时,会将这情况写到editlog,先是将editlog写到磁盘,成功后,再写到内存. fsimage 载入内存           合并edits | 新的fsimage | namenode ,替换旧的 什么时候checkpoin

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

在NameNode运行期间,HDFS的所有更新操作都是直接写到edits中,久而久之edits文件将会变得很大:虽然这对NameNode运行时候是没有什么影响的,但是我们知道当NameNode重启的时候,NameNode先将fsimage里面的所有内容映像到内存中,然后再一条一条地执行edits中的记录,当edits文件非常大的时候,会导致NameNode启动操作非常地慢,而在这段时间内HDFS系统处于安全模式,这显然不是用户要求的.能不能在NameNode运行的时候使得edits文件变小一些呢

Hadoop-2.4.1学习之创建fsimage和edits源码分析

在Hadoop中fsimage保存最新的检查点信息,edits保存自最新检查点后的命名空间的变化.在分析hdfs namenode–format的源代码时,已经明确了该过程根据配置文件的信息创建fsimage和edits文件,这篇文章具体分析一下创建fsimage和edits文件的源代码.在NameNode的format方法中,有如下的代码: FSImage fsImage = new FSImage(conf, nameDirsToFormat, editDirsToFormat); try

hadoop中fsimage和edits的区别

1.概念: fsimage保存了最新的元数据检查点. edits保存自最新检查点后的命名空间的变化. 2.工作原理: 从最新检查点后,hadoop将对每个文件的操作都保存在edits中,为避免edits不断增大,secondary namenode就会周期性合并fsimage和edits成新的fsimage,edits再记录新的变化. 这种机制有个问题:因edits存放在Namenode中,当Namenode挂掉,edits也会丢失,导致利用secondary namenode恢复Namenod

Hadoop集群管理 fsimage和edits工作机制内幕

一. fsiamges文件通常是整个集群的元数据信息.每次对它的修改很好内存,io. 所以引入了edits 文件.存放每次对元数据修改的记录,并通过Secondary Namenode定期的合并. 二.过程 1.Secondary Namenode请求edits和fsimage合并. 2.Namenode停止对edits文件的修改,并生成edits.new文件,存储在合并期间出现的对元数据的修改 3.Secondary Namenode通过http get方式获取edits文件和fsimages

fsimage 和 edits log

standby NN每隔一段时间(由参数dfs.ha.tail-edits.period决定,默认是60s)去检查Journal node上新的Edits log文件. standby NN每隔一段时间(由参数dfs.namenode.checkpoint.check.period决定,默认是60s)去检查是否满足建立checkpoint的条件. 条件有两个: (1) 距离上次checkpoint的时间间隔 >= ${dfs.namenode.checkpoint.period}. 默认一小时.

HDFS镜像文件fsimage和编辑日志文件edits

镜像文件和编辑日志文件 1)概念 namenode被格式化之后,将在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current目录中产生如下文件 edits_0000000000000000000 fsimage_0000000000000000000.md5 seen_txid VERSION (1)Fsimage文件:HDFS文件系统元数据的一个永久性的检查点,其中包含HDFS文件系统的所有目录和文件inode的序列化信息(id.类型.目录.所属用户

HDFS:edit log & fsimage

在NameNode的${dfs.namenode.name.dir}/current目录下,有这样几个文件: 在数据库系统中,log是用于记录写操作的日志的,并使用该Log进行备份.恢复数据等工作.有关写的操作的记录的,目前见过了两种:关系型数据库的log,HBase的WALs等等都是这样的写操作的日志. HDFS也采用了类似的机制.在HDFS中,会将第一次的文件操作,看作一个事务.譬如说一个文件的创建.文件内容追加.文件移动等等写操作.从这个角度来看呢,fsimage文件就相当于HDFS 的元