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后集群启动正常。

<property>
  <name>dfs.secondary.http.address</name>
  <value>second_namenode:50090</value>
  <description>
    The secondary namenode http server address and port.
    If the port is 0 then the server will start on a free port.
  </description>
</property> 

示例如下：

环境如下(停止所有服务stop-all.sh)：

master：master   192.168.1.106

slave：slave1    192.168.1.107

            slave2    192.168.1.108

1、修改master（改为slave其中的一个）#master 其实配置的是secondnamenode的节点

slave1

 

2、修改core-site.xml

<property>
<name>fs.default.name</name>
<value>hdfs://master:9000</value>
</property>

 

3、修改hdfs-site.xml

<property>
<name>dfs.http.address</name>
<value>master:50070</value>
</property>

 

4、将配置复制到其他slave

[grid@master ~]$ scp -r ./hadoop-1.2.1 grid@192.168.1.107:/home/grid

[grid@master ~]$ scp -r ./hadoop-1.2.1 grid@192.168.1.108:/home/grid

 

5、启动服务

[grid@master hadoop-1.2.1]$ ./bin/start-all.sh

 

6、使用jps查看进程，以下进程表明secondnamenode已经成功分离部署