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