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}. 默认一小时.
      
（2） Edits中的事务条数达到${dfs.namenode.checkpoint.txns}限制. 默认1,000,000.

满足checkpoint条件时, standby NN会做一次checkpoint,记录standby NN合并到了哪个Edits log文件., 然后合并新的Edits log到fsimage, 并将fsimage同步到active NN上

如果active NN挂了, standby NN会检查上一次checkpoint之后JN上新的Edits log文件, 并合并成fsimage, 取代active NN.

时间： 2024-10-04 22:32:15

fsimage 和 edits log的相关文章

【转】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

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

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

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

ZooKeeper基础

简介 Apache ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,由Client和Server构成,Server提供了一致性复制和存储服务,Client包含一个简单的原语集,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等.ZooKeeper的设计非常易于编程,ZooKeeper维护着一个hierarchal(层次)的名字空间,它采用树形的数据结构,类似于标准文件系统.因为想要从零实现一个分布式协作服务是非常难的.最常见的问题就是竞争条件和死锁.Apache Zo

大数据学习笔记2--hdfs工作原理及源码分析

windows下配置hadoop hadoop 安装包解压,路径不要有特殊字符 lib和bin直接解压出来的不可用,需要自己重新编译 配置环境变量:HADOOP_HOME,path中添加:bin目录 namenode 整个文件系统的管理节点.它维护着整个文件系统的文件目录树,文件/目录的元信息和每个文件对应的数据块列表.接收用户的操作请求. 响应客户端的请求,上传文件: client申请上传文件,namenode查看元数据信息,查看客户端申请的路径是否已存在 namenode返回可用的datan

Hadoop实战笔记

一.基础知识(里面的内容包含大部分的Hadoop的内容,耐心的看完,肯定有收获,如有不同可留言或者上某度) 1.Hadoop生态系统介绍 (1)HBase Nosql 数据库,key-value存储 最大化利用内存 (2)HDFS 简介:Hadoop distribute file system 分布式文件系统 最大化利用磁盘 HDFS的设计原则: 文件以块(block)方式存储,默认块(64M)(如果一个文件没有64M,仍然占用一个block,但是物理内存可能没有没有64M),也可以自定义 通

HDFS系列 -- HDFS预研

目录 1 HDFS概述 1.1 HDFS基本特性 1.2 HDFS不足之处 1.3 HDFS系统架构 1.4 HDFS基本组成 1.4.1 NameNode 1.4.2 DataNode 1.4.3 Secondary NameNode 2.1 HDFS运行原理 2.2 HDFS写数据流程 2.3 HDFS读数据流程 3.1. HA概述 3.2.NameNode 的主备切换实现 3.2.1. HealthMonitor 实现分析 3.2.2. ActiveStandbyElector 实现分析