深入理解namenode和secondarynamenode工作机制

一、namenode启动过程

1. hadoop的hive-site配置文件中的dfs.namenode.name.dir属性，指定了namenode进程读取数据的目录，该目录下包含了hdfs文件系统的元信息。

2. 首次安装hadoop，执行hdfs namenode -format命令格式化文件系统， 打开dfs.namenode.name.dir属性配置目录，该current目录下会产生以下文件：

[wangzhe@node1 ~]$ ls -l /data/hadoop/name/current/
总用量 16
-rw-rw-r--. 1 wangzhe wangzhe 324 3月  22 23:47 fsimage_0000000000000000000
-rw-rw-r--. 1 wangzhe wangzhe  62 3月  22 23:47 fsimage_0000000000000000000.md5
-rw-rw-r--. 1 wangzhe wangzhe   2 3月  22 23:47 seen_txid
-rw-rw-r--. 1 wangzhe wangzhe 204 3月  22 23:47 VERSION

fsimage_0000000000000000000文件是hdfs系统元数据，它记录着整个文件目录结构，以及文件每个数据块所在节点位置，无法直接使用cat命令查看，先使用hdfs oiv命令将其导出为xml文件格式：

hdfs oiv -p XML -i fsimage_0000000000000000000 -o ./fsimage.xml

seen_txid文件里记录了正在执行的事务id，初始化时为0：

[wangzhe@node1 current]$ cat seen_txid 
0

3. 向集群添加测试文件：

hdfs dfs -mkdir /data
hdfs dfs -put runSparkJar.sh /data

上传文件操作会在namenode元数据目录下产生编辑日志文件内容，edit_xxx文件里记录着这些操作：

[wangzhe@node1 current]$ ls -lh
总用量 1.1M
-rw-rw-r--. 1 wangzhe wangzhe   42 3月  23 00:04 edits_0000000000000000001-0000000000000000002
-rw-rw-r--. 1 wangzhe wangzhe  656 3月  23 00:05 edits_0000000000000000003-0000000000000000011
-rw-rw-r--. 1 wangzhe wangzhe   42 3月  23 00:06 edits_0000000000000000012-0000000000000000013
-rw-rw-r--. 1 wangzhe wangzhe   42 3月  23 00:07 edits_0000000000000000014-0000000000000000015
-rw-rw-r--. 1 wangzhe wangzhe   42 3月  23 00:08 edits_0000000000000000016-0000000000000000017
-rw-rw-r--. 1 wangzhe wangzhe   42 3月  23 00:09 edits_0000000000000000018-0000000000000000019
-rw-rw-r--. 1 wangzhe wangzhe 1.0M 3月  23 00:09 edits_inprogress_0000000000000000020
-rw-rw-r--. 1 wangzhe wangzhe  324 3月  22 23:47 fsimage_0000000000000000000
-rw-rw-r--. 1 wangzhe wangzhe   62 3月  22 23:47 fsimage_0000000000000000000.md5
-rw-rw-r--. 1 wangzhe wangzhe    3 3月  23 00:09 seen_txid
-rw-rw-r--. 1 wangzhe wangzhe  204 3月  22 23:47 VERSION

hdfs每个操作都会产生一个事务id，edits_0000000000000000001-0000000000000000002文件代表这里面记录了两个事务操作，id为1-2。edits_inprogress_0000000000000000020表示这个文件正在被编辑，且事务id从20开始。此时seen_txid内容如下：

[wangzhe@node1 current]$ cat seen_txid 
20

而此时fsimage文件并发生任何变化(从前后两幅图文件大小对比可以看出)，既然fsimage文件是文件系统元数据，那么它为什么不改变呢？谜底接下来揭晓。

4. 每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的。当上传一个文件到hdfs系统时，namenode并不会去更新fsimage文件，只是把该次操作记录到editlogs文件中，然后更新了内存中的元数据信息。因为客户端读取文件时都是直接与内存中的元数据信息打交道，所以客户端看到的总是正确的结果。

5. 当编辑日志文件非常大时，namenode进程需要花费非常长的时间合并editlogs和fsimage文件，导致集群启动长时间等待。所以需要一种机制定期将editlogs和fsimage文件合并，而不是等待每次namenode重启时合并，而这正是Secondary Namenode进程存在的意义。

二、Secondary NameNode工作原理

1. Secondary NameNode定期询问namenode是否需要执行editlogs和fsimage文件合并操作。直接带回namenode检查结果。

2. Secondary NameNode请求执行文件合并操作。

3. namenode滚动正在写的edits日志(即将正在写的edits_progress文件变为edits_0000000000xxx文件)

4. 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode

5. Secondary NameNode加载编辑日志和镜像文件到内存，并合并。

6. 生成新的镜像文件fsimage.chkpoint

7. 拷贝fsimage.chkpoint到namenode

8. namenode将fsimage.chkpoint重新命名成fsimage

三、Secondary Namenode checkpoint时间参数设置

1. 通常情况下，SecondaryNameNode每隔一小时执行一次文件合并操作(checkpoint)。[hdfs-default.xml]

<property>

<name>dfs.namenode.checkpoint.period</name>

<value>3600</value>

</property>

2. SecondaryNameNode一分钟请求检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。

<property>

<name>dfs.namenode.checkpoint.txns</name>

<value>1000000</value>

<description>操作动作次数</description>

</property>

<property>

<name>dfs.namenode.checkpoint.check.period</name>

<value>60</value>

<description> 1分钟检查一次操作次数</description>

</property>