注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

A small step

Judgement Must

 
 
 

日志

 
 
关于我

不要因为急着赶路,让自己的步伐杂乱。远方是既定的目标,但路上才是最重要的经历!

网易考拉推荐

namenode secondarynamenode  

2015-05-18 14:41:01|  分类: hadoop |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

NameNode将对文件系统的改动追加保存到本地文件系统上的一个日志文件(edits)。当一个NameNode启动时,它首先从一个映像文件(fsimage)中读取HDFS的状态,接着应用日志文件中的edits操作。然后它将新的HDFS状态写入(fsimage)中,并使用一个空的 edits文件开始正常操作。因为NameNode只有在启动阶段才合并fsimage和edits,所以一段时间后日志文件可能会变得非常庞大,特别是对大型的集群。日志文件太大的另一个副作用是下一次NameNode启动会花很长时间。

 

Secondary NameNode定期合并fsimage和edits日志,将edits日志文件大小控制在一个限度下。因为内存需求和NameNode在一个数量级上,所以通常secondary NameNode(运行在单独的物理机器上)和NameNode运行在不同的机器上。Secondary NameNode通过bin/start-dfs.sh在conf/masters中指定的节点上启动。

Secondary NameNode的检查点进程启动,是由两个配置参数控制的:

    * fs.checkpoint.period,指定连续两次检查点的最大时间间隔, 默认值是1小时。
    * fs.checkpoint.size定义了edits日志文件的最大值,一旦超过这个值会导致强制执行检查点(即使没到检查点的最大时间间隔)。默认值是64MB。

 

Secondary NameNode保存最新检查点的目录与NameNode的目录结构相同。所以NameNode可以在需要的时候读取Secondary NameNode上的检查点镜像。

 

如果NameNode上除了最新的检查点以外,所有的其他的历史镜像和edits文件都丢失了, NameNode可以引入这个最新的检查点。以下操作可以实现这个功能:

    * 在配置参数dfs.name.dir指定的位置建立一个空文件夹;
    * 把检查点目录的位置赋值给配置参数fs.checkpoint.dir;
    * 启动NameNode,并加上-importCheckpoint。

 

NameNode会从fs.checkpoint.dir目录读取检查点,并把它保存在dfs.name.dir目录下。如果dfs.name.dir目录下有合法的镜像文件,NameNode会启动失败。 NameNode会检查fs.checkpoint.dir目录下镜像文件的一致性,但是不会去改动它。

 

SecondaryNameNode工作流程:
SecondaryNameNode节点通知NameNode节点生成新的日志文件,以后的日志都写到新的日志文件中。
SecondaryNameNode节点用http get从NameNode节点获得fsimage文件及旧的日志文件。
SecondaryNameNode节点将fsimage文件加载到内存中,并执行日志文件中的操作,然后生成新的fsimage文件。
SecondaryNameNode节点将新的fsimage文件用http post传回NameNode节点上。
NameNode节点可以将旧的fsimage文件及旧的日志文件,换为新的fsimage文件和新的日志文件(第一步生成的),然后更新fstime文件,写入此次checkpoint的时间。
这样NameNode节点中的fsimage文件保存了最新的checkpoint的元数据信息,日志文件也重新开始,不会变的很大了。


NameNode

NameNode主要是用来保存HDFS的元数据信息,比如命名空间信息,块信息等。当它运行的时候,这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。

上面的这张图片展示了NameNode怎么把元数据保存到磁盘上的。这里有两个不同的文件:

  1. fsimage - 它是在NameNode启动时对整个文件系统的快照
  2. edit logs - 它是在NameNode启动后,对文件系统的改动序列

只有在NameNode重启时,edit logs才会合并到fsimage文件中,从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的,这也意味着当NameNode运行了很长时间后,edit logs文件会变得很大。在这种情况下就会出现下面一些问题:

  1. edit logs文件会变的很大,怎么去管理这个文件是一个挑战。
  2. NameNode的重启会花费很长时间,因为有很多改动[笔者注:在edit logs中]要合并到fsimage文件上。
  3. 如果NameNode挂掉了,那我们就丢失了很多改动因为此时的fsimage文件非常旧。[笔者注: 笔者认为在这个情况下丢失的改动不会很多, 因为丢失的改动应该是还在内存中但是没有写到edit logs的这部分。]

因此为了克服这个问题,我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件,这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的,Windows的恢复点机制允许我们对OS进行快照,这样当系统发生问题时,我们能够回滚到最新的一次恢复点上。

现在我们明白了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。那么,这些跟Secondary NameNode又有什么关系呢?

Secondary NameNode

SecondaryNameNode就是来帮助解决上述问题的,它的职责是合并NameNode的edit logs到fsimage文件中。

上面的图片展示了Secondary NameNode是怎么工作的。

  1. 首先,它定时到NameNode去获取edit logs,并更新到fsimage上。[笔者注:Secondary NameNode自己的fsimage]
  2. 一旦它有了新的fsimage文件,它将其拷贝回NameNode中。
  3. NameNode在下次重启时会使用这个新的fsimage文件,从而减少重启的时间。

Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。

现在,我们明白了Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起,让我们养成一个习惯,称呼它为检查点节点吧。

  评论这张
 
阅读(5)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018