1 - NameNode 的启动流程
1）Loading fsimage - 从 fsimage file 中读取最新的元数据快照（最近生成的 fsimage_xx）；
2）Loading edits - 读取 fsimage_xx 之后的所有事务的 edit logs，将 edit logs 中的操作重新执行一遍，此时 NameNode 就恢复到上次停止时的状态了；
3）checkpoint - 将当前状态写入新的 checkpoint 中，即产生一个新的 fsimage_xx 文件；
4）Safe mode - 等待各个 DataNodes 汇报自己的 block 信息，形成 blockMap，然后退出安全模式。
此时 NameNode 启动结束，等待接受用户的操作请求，并把用户操作写入新的 edit log 中，定期进行 checkpoint，对元数据执行快照。
2 - NameNode 的元数据
NameNode 的所有操作及整个集群的状态都存储在 元数据 中，元数据都保存在 fsImage 和 eidts 文件中。
它们的主要作用是：在集群启动时将集群的状态恢复到关闭前的状态。
它们的位置需要在 hdfs-site.xml 文件中指定：
<!-- NameNode 元数据的存放目录 -->
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/Users/healchow/data/hadoop/namenode</value>
</property>
<!-- NameNode 日志文件的存放目录 -->
<property>
<name>dfs.namenode.edits.dir</name>
<value>file:/Users/healchow/data/hadoop/namenode/edits</value
</property>
2.1 EditLog 操作日志
1）客户端对 HDFS 的写操作会首先被记录在 edits 文件中；
2）edits 修改完成之后，会再更新内存中的文件系统镜像；
3）记录在 EditLog 中的每一个操作又称为一个事务，每个事务有一个整数形式的事务 id 作为编号。
（临时总结，不一定对）EditLog 就是事务日志，主要作用是用来记录写操作，以支持系统的恢复。
2.2 查看 EditLog 文件
EditLog 会被切割成很多段，每一段称为一个 Segment。正在写入的 Segment 处于 in-progress 状态，其文件名形如 edits_inprogress_${start_txid}，其中 ${start_txid} 表示这个 Segment 的起始事务 id。
已经写入完成的 Segment 处于 finalized 状态，其文件名形如 edits_${start_txid}-${end_txid}，其中 ${start_txid} 表示这个 Segment 的起始事务 id，${end_txid} 表示这个 Segment 的结束事务 id。
查看 edits 中的文件信息
hdfs oev 回车后会显示命令的帮助信息：
cd ~/data/hadoop/namenode
hdfs oev -i edits_0000000000000000865-0000000000000000866 -p XML -o myedit.xml
2.3 FSImage 元数据镜像
1）FSImage 是 NameNode 中关于元数据的镜像，一般称为检查点的镜像；
2）FSImage 是 NameNode 自上次 checkpoint 之后生成的元数据，并不是实时的数据；
3）FSImage 保存了 NameNode 管理下的所有 DataNode 的文件和目录信息：
FSImage 默认会保存2个，由属性 dfs.namenode.num.checkpoints.retained 控制。
内存中的 FSImage 用于 NameNode 向客户端提供读服务，而 EditLog 仅仅只是在数据恢复的时候发挥作用。
2.4 查看 FSImage 文件
FSImage 文件的文件名形如 fsimage_${end_txid}，其中 ${end_txid} 表示这个 FSImage 文件的结束事务 id。
查看 fsimage 中的文件信息：
hdfs oev 回车后会显示命令的帮助信息：
cd ~/bigdata/data/hadoop/namenode
hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml
3 - Checkpoint 检查点操作
3.1 为什么要 Checkpoint
HDFS 的每个写操作都会写入EditLog 中，随着时间的积累 EditLog 会变的很大，极端情况下会占满整个磁盘。
另外，由于 NameNode 在启动的时候，需要将 EditLog 中的操作重新执行一遍，过大的 EditLog 会延长 NameNode 的启动时间。
所以，通过 Checkpoint 定期对元数据进行合并。
3.2 Checkpoint 的过程
Checkpoint 会把 FSImage 和 EditLog 的内容进行合并生成一个新的 FSImage。
这样在 NameNode 启动的时候就不用将巨大的 EditLog 中的事务再执行一遍，而是直接加载合并之后的新 FSImage ，然后重新执行未被合并的 EditLog 文件就可以了。
4 - SNN 辅助管理 FSImage 和 EditLog
4.1 相关配置
SNN（SecondaryNameNode，备份 NameNode）节点要在 conf/masters 文件中指定；
SNN 的 hdfs-site.xml 文件中需要配置下述参数：
<property>
<name>dfs.http.address</name>
<value>host:50070</value>
</property>
SecondaryNameNode 会定期合并 FSImage 和 EditLog，把 EditLog的体积控制在一个合理的范围内。
Checkpoint 的触发条件取决于两个参数，可在 NameNode / SNN 的 core-site.xml 中配置：
<!-- 两次 checkpoint 的时间间隔，默认3600秒，即1小时 -->
<property>
<name>dfs.namenode.checkpoint.period</name>
<value>3600s</value>
</property>
<!-- 新生成的 EditLog 中积累的事务数量达到了阈值，默认1000000次。优先级高于上述参数 -->
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>1000000</value>
</property>
<!-- 每隔多久检查一次 HDFS 未记录到检查点的事务数，默认60秒 -->
<property>
<name>dfs.namenode.checkpoint.check.period</name>
<value>60s</value>
</property>
<!-- 一次记录文件的大小，默认64MB -->
<property>
<name>fs.checkpoint.size</name>
<value>67108864</value>
</property>
4.2 管理流程
SecondaryNameNode 通知 NameNode 停止使用 EditLog，暂时将新的写操作存放到
edits.new文件；SecondaryNameNode 通过 HTTP 的 GET 请求，从 NameNode 中获取 FSImage 和 EditLog，将它们加载到内存中；
SecondaryNameNode 合并 FSImage 和 EditLog，合并完成后生成新的 FSImage；
SecondaryNameNode 通过 HTTP POST 请求方式，将新的 FSImage 发送给 NameNode；
NameNode 把原有的 FSImage 替换为新的 FSImage，把 edits.new 变成 edits，同时更新 fstime（即最后一个检查点的时间戳）。