5.2 SecondaryNameNode

存在的意义

edits log会随着对文件系统的操作而无限制地增长，这对正在运行的NameNode而言没有任何影响，如果NameNode重启，则需要很长的时间执行edits log的记录以更新fsimage（元数据镜像文件）。在此期间，整个系统不可用。定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits log的合并。

SecondaryNameNode要和NameNode拥有相同的内存。对大的集群，SecondaryNameNode运行于一台专用的物理主机。

存储结构

xxxxxxxxxx
[root@node1 name]# pwd
/var/itbaizhan/hadoop/full/dfs/name
|-current  
|   |-edits_0000000000000000001-0000000000000000008
|   |-edits_0000000000000000009-0000000000000000038
|   |-edits_0000000000000000039-0000000000000000040
|   |-edits_0000000000000000041-0000000000000000041
|   |-edits_0000000000000000042-0000000000000000043
|   |-edits_0000000000000000044-0000000000000000045
|   |-edits_0000000000000000046-0000000000000000047
|   |-edits_0000000000000000048-0000000000000000049
|   |-edits_0000000000000000050-0000000000000000051
|   |-edits_0000000000000000052-0000000000000000053
|   |-edits_0000000000000000054-0000000000000000054
|   |-edits_0000000000000000055-0000000000000000056
|   |-fsimage_0000000000000000054
|   |-fsimage_0000000000000000054.md5
|   |-fsimage_0000000000000000056
|   |-fsimage_0000000000000000056.md5
|   |-edits_inprogress_0000000000000000057
|   |-seen_txid  #57
|   |-VERSION
|-in_use.lock
[root@node2 namesecondary]# pwd
/var/itbaizhan/hadoop/full/dfs/namesecondary
|-current  
|   |-edits_0000000000000000001-0000000000000000008
|   |-edits_0000000000000000009-0000000000000000038
|   |-edits_0000000000000000039-0000000000000000040
|   |-edits_0000000000000000041-0000000000000000041
|   |-edits_0000000000000000042-0000000000000000043
|   |-edits_0000000000000000044-0000000000000000045
|   |-edits_0000000000000000046-0000000000000000047
|   |-edits_0000000000000000048-0000000000000000049
|   |-edits_0000000000000000050-0000000000000000051
|   |-edits_0000000000000000052-0000000000000000053
|   |-edits_0000000000000000055-0000000000000000056
|   |-fsimage_0000000000000000054
|   |-fsimage_0000000000000000054.md5
|   |-fsimage_0000000000000000056
|   |-fsimage_0000000000000000056.md5
|   |-VERSION
|-in_use.lock

1、SecondaryNameNode中checkpoint目录布局（dfs.namenode.checkpoint.dir）和NameNode中的基本一样。

2、如果NameNode完全坏掉，可以快速地从SecondaryNameNode恢复。有可能丢数据

3、如果SecondaryNameNode直接接手NameNode的工作，需要在启动NameNode进程的时候添加-importCheckpoint选项。该选项会让NameNode从由dfs.namenode.checkpoint.dir属性定义的路径中加载最新的checkpoint数据，但是为了防止元数据的覆盖，要求dfs.namenode.name.dir定义的目录中没有内容。

工作流程

edits_inprogress_00000000001_0000000019 seen_txid=20

1、secondarynamenode请求namenode生成新的edits log文件(edits_inprogress_...)并向其中写日志。NameNode会在所有的存储目录中更新seen_txid文件

2、SecondaryNameNode通过HTTP GET的方式从NameNode下载fsimage和edits文件到本地。

3、SecondaryNameNode将fsimage加载到自己的内存，并根据edits log更新内存中的fsimage信息，然后将更新完毕之后的fsimage写到磁盘上。

4、SecondaryNameNode通过HTTP PUT将新的fsimage文件发送到NameNode，NameNode将该文件保存为.ckpt的临时文件备用。

5、NameNode重命名该临时文件并准备使用。此时NameNode拥有一个新的fsimage文件和一个新的很小的edits log文件（可能不是空的，因为在SecondaryNameNode合并期间可能对元数据进行了读写操作）。管理员也可以将NameNode置于safemode，通过hdfs dfsadmin -saveNamespace命令来进行edits log和fsimage的合并。

检查点创建时机:对于创建检查点（checkpoint）的过程，有三个参数进行配置：

xxxxxxxxxx
<!-- 默认情况下，SecondaryNameNode每个小时进行一次checkpoint合并 -->
<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600s</value>
</property>
<!-- 一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次 -->
<property>
  <name>dfs.namenode.checkpoint.txns</name>
  <value>1000000</value>
<description>操作动作次数</description>
</property>
<property>
  <name>dfs.namenode.checkpoint.check.period</name>
  <value>60s</value>
<description> 1分钟检查一次操作次数</description>
</property >

合并条件总结：1、每小时一次，2、不足一小时，则只要edits log中记录的事务数达到了1000000，则合并。

hdfs-default.xml，如果想修改这几个参数的话，直接在hdfs-site.xml中进行配置即可。