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

转载 2015年11月19日 18:02:51


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


在Hadoop 2.x中解决了NameNode的单点故障问题;同时SecondaryName已经不用了,而之前的Hadoop 1.x中是通过SecondaryName来合并fsimage和edits以此来减小edits文件的大小,从而减少NameNode重启的时间。而在Hadoop 2.x中已经不用SecondaryName,那它是怎么来实现fsimage和edits合并的呢?首先我们得知道,在Hadoop 2.x中提供了HA机制(解决NameNode单点故障),可以通过配置奇数个JournalNode来实现HA,如何配置今天就不谈了!HA机制通过在同一个集群中运行两个NN(active NN & standby NN)来解决NameNode的单点故障,在任何时间,只有一台机器处于Active状态;另一台机器是处于Standby状态。Active NN负责集群中所有客户端的操作;而Standby NN主要用于备用,它主要维持足够的状态,如果必要,可以提供快速的故障恢复。
  为了让Standby NN的状态和Active NN保持同步,即元数据保持一致,它们都将会和JournalNodes守护进程通信。当Active NN执行任何有关命名空间的修改,它需要持久化到一半以上的JournalNodes上(通过edits log持久化存储),而Standby NN负责观察edits log的变化,它能够读取从JNs中读取edits信息,并更新其内部的命名空间。一旦Active NN出现故障,Standby NN将会保证从JNs中读出了全部的Edits,然后切换成Active状态。Standby NN读取全部的edits可确保发生故障转移之前,是和Active NN拥有完全同步的命名空间状态(更多的关于Hadoop 2.x的HA相关知识,可以参考本博客的《Hadoop2.2.0中HDFS的高可用性实现原理》)。
  那么这种机制是如何实现fsimage和edits的合并?在standby NameNode节点上会一直运行一个叫做CheckpointerThread的线程,这个线程调用StandbyCheckpointer类的doWork()函数,而doWork函数会每隔Math.min(checkpointCheckPeriod, checkpointPeriod)秒来坐一次合并操作,相关代码如下:

01 try {
02           Thread.sleep(1000 * checkpointConf.getCheckPeriod());
03         catch (InterruptedException ie) {
04 }
05  
06 public long getCheckPeriod() {
07     return Math.min(checkpointCheckPeriod, checkpointPeriod);
08 }
09  
10 checkpointCheckPeriod = conf.getLong(
11         DFS_NAMENODE_CHECKPOINT_CHECK_PERIOD_KEY,
12         DFS_NAMENODE_CHECKPOINT_CHECK_PERIOD_DEFAULT);
13          
14 checkpointPeriod = conf.getLong(DFS_NAMENODE_CHECKPOINT_PERIOD_KEY,
15                                 DFS_NAMENODE_CHECKPOINT_PERIOD_DEFAULT);

上面的checkpointCheckPeriod和checkpointPeriod变量是通过获取hdfs-site.xml以下两个属性的值得到:

01 <property>
02   <name>dfs.namenode.checkpoint.period</name>
03   <value>3600</value>
04   <description>The number of seconds between two periodic checkpoints.
05   </description>
06 </property>
07  
08 <property>
09   <name>dfs.namenode.checkpoint.check.period</name>
10   <value>60</value>
11   <description>The SecondaryNameNode and CheckpointNode will poll the NameNode
12   every 'dfs.namenode.checkpoint.check.period' seconds to query the number
13   of uncheckpointed transactions.
14   </description>
15 </property>

当达到下面两个条件的情况下,将会执行一次checkpoint:

01 boolean needCheckpoint = false;
02 if (uncheckpointed >= checkpointConf.getTxnCount()) {
03      LOG.info("Triggering checkpoint because there have been "+
04                 uncheckpointed + " txns since the last checkpoint, which " +
05                 "exceeds the configured threshold " +
06                 checkpointConf.getTxnCount());
07      needCheckpoint = true;
08 else if (secsSinceLast >= checkpointConf.getPeriod()) {
09      LOG.info("Triggering checkpoint because it has been " +
10             secsSinceLast + " seconds since the last checkpoint, which " +
11              "exceeds the configured interval " + checkpointConf.getPeriod());
12      needCheckpoint = true;
13 }

  当上述needCheckpoint被设置成true的时候,StandbyCheckpointer类的doWork()函数将会调用doCheckpoint()函数正式处理checkpoint。当fsimage和edits的合并完成之后,它将会把合并后的fsimage上传到Active NameNode节点上,Active NameNode节点下载完合并后的fsimage,再将旧的fsimage删掉(Active NameNode上的)同时清除旧的edits文件。步骤可以归类如下:
  (1)、配置好HA后,客户端所有的更新操作将会写到JournalNodes节点的共享目录中,可以通过下面配置

1 <property>
2   <name>dfs.namenode.shared.edits.dir</name>
3   <value>qjournal://XXXX/mycluster</value>
4 </property>
5  
6 <property>
7   <name>dfs.journalnode.edits.dir</name>
8   <value>/export1/hadoop2x/dfs/journal</value>
9 </property>

  (2)、Active Namenode和Standby NameNode从JournalNodes的edits共享目录中同步edits到自己edits目录中;
  (3)、Standby NameNode中的StandbyCheckpointer类会定期的检查合并的条件是否成立,如果成立会合并fsimage和edits文件;
  (4)、Standby NameNode中的StandbyCheckpointer类合并完之后,将合并之后的fsimage上传到Active NameNode相应目录中;
  (5)、Active NameNode接到最新的fsimage文件之后,将旧的fsimage和edits文件清理掉;
  (6)、通过上面的几步,fsimage和edits文件就完成了合并,由于HA机制,会使得Standby NameNode和Active NameNode都拥有最新的fsimage和edits文件(之前Hadoop 1.x的SecondaryNameNode中的fsimage和edits不是最新的)


相关文章推荐

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

在《Hadoop 1.x中fsimage和edits合并实现》文章中,我们谈到了Hadoop 1.x上的fsimage和edits合并实现,里面也提到了Hadoop 2.x版本的fsimage...

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

在《Hadoop 1.x中fsimage和edits合并实现》文章中,我们谈到了Hadoop 1.x上的fsimage和edits合并实现,里面也提到了Hadoop 2.x版本的fsimage和e...

Hadoop1.0中fsimage和edits的合并

在NameNode运行期间,HDFS的所有更新操作都是直接写到edits中的,所以edits这个文件会渐渐变大,这虽然对NameNode运行期间没影响,但是我们知道,当NameNode启动的时候,它会...

【总结】Hadoop-2.X HA模式下的FSImage和EditsLog合并过程

原文:http://blog.csdn.net/dabokele/article/details/51686257 补充了一下NameNode启动过程中有关FSImage与EditsLog的相关...

Hadoop-2.X HA模式下的FSImage和EditsLog合并过程

Hadoop-2.X中HA模式下FSImage和EditsLog的checkpoint操作过程分析

Hadoop 2.x之HDFS利用QJM实现HA高可用

【启动顺序】 1、关闭防火墙# service iptables stop2、启动三台zookeeper# zkServer.sh start3、在其中一个namenode上格式化,这个步骤只需要操...

Hadoop中的fsimage和edits log编辑日志

转载请注明出处: 【http://datasearch.ruc.edu.cn/~boliangfeng/blog】,谢谢。 在hadoopor论坛里看到这样的问题,这里做个回答。 ...

Hadoop文件系统元数据fsimage和编辑日志edits

在《Hadoop NameNode元数据相关文件目录解析》文章中提到NameNode的$dfs.namenode.name.dir/current/文件夹的几个文件: 1...

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

在Hadoop中fsimage保存最新的检查点信息,edits保存自最新检查点后的命名空间的变化。在分析hdfs namenode–format的源代码时,已经明确了该过程根据配置文件的信息创建fsi...

Hadoop-2.4.1学习之edits和fsimage查看器

在hadoop中edits和fsimage是两个至关重要的文件,其中edits负责保存自最新检查点后命名空间的变化,起着日志的作用,而fsimage则保存了最新的检查点信息。这个两个文件中的内容使用普...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

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