[转载]hadoop SecondNamenode详解

SecondNamenode名字看起来很象是对第二个Namenode,要么与Namenode一样同时对外提供服务,要么相当于Namenode的HA。
真正的了解了SecondNamenode以后,才发现事实并不是这样的。
下面这段是Hadoop对SecondNamenode的准确定义:

* The Secondary Namenode is a helper to the primary Namenode.
* The Secondary is responsible for supporting periodic checkpoints
* of the HDFS metadata. The current design allows only one Secondary
* Namenode per HDFs cluster.
*
* The Secondary Namenode is a daemon that periodically wakes
* up (determined by the schedule specified in the configuration),
* triggers a periodic checkpoint and then goes back to sleep.
* The Secondary Namenode uses the ClientProtocol to talk to the
* primary Namenode.

SecondNamenode是对主Namenode的一个补充,它会周期的执行对HDFS元数据的检查点。
当前的设计仅仅允许每个HDFS只有单个SecondNamenode结点。
SecondNamenode是有一个后台的进程,会定期的被唤醒(唤醒的周期依赖相关配置)执行检查点任务,然后继续休眠。
它使用ClientProtocol协议与主Namenode通信。

1,检查点到底是做什么用的呢?
先抛开SecondNamenode不说,先介绍下Namenode中与检查点相关的两个文件,以及他们之间的关系。
fsimage文件与edits文件是Namenode结点上的核心文件
Namenode中仅仅存储目录树信息,而关于BLOCK的位置信息则是从各个Datanode上传到Namenode上的。
Namenode的目录树信息就是物理的存储在fsimage这个文件中的,当Namenode启动的时候会首先读取fsimage这个文件,将目录树信息装载到内存中。
而edits存储的是日志信息,在Namenode启动后所有对目录结构的增加,删除,修改等操作都会记录到edits文件中,并不会同步的记录在fsimage中。
而当Namenode结点关闭的时候,也不会将fsimage与edits文件进行合并,这个合并的过程实际上是发生在Namenode启动的过程中。
也就是说,当Namenode启动的时候,首先装载fsimage文件,然后在应用edits文件,最后还会将最新的目录树信息更新到新的fsimage文件中,然后启用新的edits文件。
整个流程是没有问题的,但是有个小瑕疵,就是如果Namenode在启动后发生的改变过多,会导致edits文件变得非常大,大得程度与Namenode的更新频率有关系。
那么在下一次Namenode启动的过程中,读取了fsimage文件后,会应用这个无比大的edits文件,导致启动时间变长,并且不可能控,可能需要启动几个小时也说不定。

Namenode的edits文件过大的问题,也就是SecondeNamenode要解决的主要问题。
SecondNamenode会按照一定规则被唤醒,然后进行fsimage文件与edits文件的合并,防止edits文件过大,导致Namenode启动时间过长。

2,检查点被唤醒的条件?
以前的文章里面曾经写过相关内容,这里在回顾一下。
控制检查点的参数有两个,分别是:
fs.checkpoint.period:单位秒,默认值3600,检查点的间隔时间,当距离上次检查点执行超过该时间后启动检查点
fs.checkpoint.size:单位字节,默认值67108864,当edits文件超过该大小后,启动检查点
上面两个条件是或的关系,主要满足启动一个条件,检查点即被唤醒

3,检查点执行的过程?
a,初始化检查点
b,通知Namenode启用新的edits文件
c,从Namenode下载fsimage和edits文件
d,调用loadFSImage装载fsimage
e,调用loadFSEdits应用edits日志
f,保存合并后的目录树信息到新的image文件中
g,将新产生的image上传到Namenode中,替换原来的image文件
h,结束检查点

4,SecondNamenode最好于Namenode部署到不同的服务器
应该在merge的过程中,SecondNamenode对内存的需求与Namenode是相同的,所以对于那些大型的生产系统中,如果将两者部署到同台服务器上,在内存上会出现瓶颈。
所以最好将他们分别部署到不同的服务器。
修改hadoop配置文件的master文件。

5,关于SecondNamenode的思考
其实检查点的执行过程最好在Namenode结点搞定,也就说能有个任务定期的将Namenode的内存结果刷新到fsimage中,而不是仅仅在Namenode启动的时候才进行一次合并。
如果可以实现定期的对Namenode执行检查点,那么SecondNamenode完全没有存在的必要了。
或者在SecondNamenode方面实现增量的刷新,每次不需要将fsimage整个装载到内存中,而仅仅将增量刷新就OK了。
不过这样会让系统变得复杂一些,可以参考oracle中的检查点的处理,还是有些复杂的。
简单就是美?!!

 FYI:在masters文件中配置second namenode后,日志报java.net.BindException: Cannot assign requested address异常,而且second namenode启动失败,反复测试发现是hdfs-site.xml中的dfs.secondary.http.address没有更改IP,更改成masters中配置的IP后集群启动正常。

dfs.secondary.http.address
  second_namenode:50090
  
    The secondary namenode http server address and port.
    If the port is 0 then the server will start on a free port.

转载自http://blog.chinaunix.net/uid-20577907-id-3524135.html

时间: 2024-11-04 11:03:45

[转载]hadoop SecondNamenode详解的相关文章

【转】Hadoop安全模式详解及配置

原文链接 http://www.iteblog.com/archives/977 在<Hadoop 1.x中fsimage和edits合并实现>文章中提到,Hadoop的NameNode在重启的时候,将会进入到安全模式.而在安全模式,HDFS只支持访问元数据的操作才会返回成功,其他的操作诸如创建.删除文件等操作都会导致失败. NameNode在重启的时候,DataNode需要向NameNode发送块的信息,NameNode只有获取到整个文件系统中有99.9%(可以配置的)的块满足最小副本才会自

Hadoop DistributedCache详解

DistributedCache是Hadoop提供的文件缓存工具,它能够自动将指定的文件分发到各个节点上,缓存到本地,供用户程序读取使用.它具有以下几个特点:缓存的文件是只读的,修改这些文件内容没有意义:用户可以调整文件可见范围(比如只能用户自己使用,所有用户都可以使用等),进而防止重复拷贝现象:按需拷贝,文件是通过HDFS作为共享数据中心分发到各节点的,且只发给任务被调度到的节点.本文将介绍DistributedCache在Hadoop 1.0和2.0中的使用方法及实现原理. Hadoop D

[转载]WebConfig配置文件详解

<?xml version="1.0"?> <!--注意: 除了手动编辑此文件以外,您还可以使用 Web 管理工具来配置应用程序的设置.可以使用 Visual Studio 中的“网站”->“Asp.Net 配置”选项. 设置和注释的完整列表在 machine.config.comments 中,该文件通常位于 "Windows"Microsoft.Net"Framework"v2.x"Config 中.--&g

Hadoop Pipeline详解[摘抄]

最近使用公司内部的一个框架写map  reduce发现没有封装hadoop streaming这些东西,查了下pipeline相关的东西 Hadoop Pipeline详解 20. Aug / hadoop / 1 Comment 一.说明Hadoop 2.x相比较于1.x有了较大的改变,像MapReduce层面架构以及代码基本上是完全重写的,在HDFS层面加入了HA,Federation等特性,代码更加层次化和易读,同时加入的PB初期可能给阅读带来障碍,熟悉之后就没有太大问题了.Pipelin

[转载] 多图详解Spring框架的设计理念与设计模式

转载自http://developer.51cto.com/art/201006/205212_all.htm Spring作为现在最优秀的框架之一,已被广泛的使用,51CTO也曾经针对Spring框架中的JDBC应用做过报道.本文将从另外一个视角试图剖析出Spring框架的作者设计Spring框架的骨骼架构的设计理念. AD: Spring作为现在最优秀的框架之一,已被广泛的使用,51CTO也曾经针对Spring框架中的JDBC应用做过报道.本文将从另外一个视角试图剖析出Spring框架的作者

(转载)maven详解

转载: http://www.cnblogs.com/hongwz/p/5456578.html Maven详解 一.前言     以前做过的项目中,没有真正的使用过Maven,只知道其名声很大,其作用是用来管理jar 包的.最近一段时间在项目过程中使用Maven,用Maven构建的web项目,其项目结构只停留在了解阶段,没有深入的使用与理解,刚好最近看了一篇关于Maven的详解:就开始深入学习一下Maven的具体应用. 二.Maven的作用 在开发中,为了保证编译通过,我们会到处去寻找jar包

【转载】log4j详解使用

log4j详解 日志论    在应用程序中输出日志有有三个目的:(1)监视代码中变量的变化情况,把数据周期性地记录到文件中供其他应用进行统计分析工作. (2)跟踪代码运行进轨迹,作为日后审计的依据. (3)担当集成开发环境中的调试器,向文件或控制台打印代码的调试信息.  Apache能用日志包(Commons Logging Package)是Apache的一个开放源代码项目,它提供了一组通用的日志接口,用户可以自由地选择实现日志接口的第三方软件.通用日志包目前支持以下日志实现: Log4J日志

深入理解Java中的流---结合Hadoop进行详解

在JavaSe的基础课程当中,可以说流是一个非常重要的概念,并且在Hadoop中得到了广泛的应用,本篇博客将围绕流进行深入的详解. (一)JavaSe中流的相关概念 1.流的定义 ①在Java当中,若一个类专门用于数据传输,则这个类称为流 ②流就是程序和设备之间嫁接以来的一根用于数据传输的管道,这个设备可以是本地硬盘,可以是内存条,也可以是网络所关联的另外一台计算机等等,其中不同管道上有不同的按钮,按下不同的按钮相当于调用不同的方法,这根带按钮的用于数据传输的管道就是流,即流就是一根管道 ③流一

Hadoop WordCount详解(二)

Hadoop集群WordCount详解(二) 源代码程序 WordCount处理过程 具体代码讲解 1.源代码程序 package org.apache.hadoop.examples; import java.io.IOException; import java.util.StringTokenizer; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.examples.WordCount.Token