HDFS学习笔记（二）——NameNode和SecondNameNode

NameNode和SecondNameNode

一些文件类型

fsimage：用来存储元数据，其中包含HDFS文件系统中的所有目录和文件inode的序列化信息，该文件在磁盘上，是HDFS中元数据的一个永久拷贝。相对内存来说，磁盘的存储特点是可靠性高，但速度慢。这个文件相当于一个大仓库，存储很多元数据信息。具体文件名形如“fsimage_000000000000000001”，并另有一个md5校验文件形如“fsimage_000000000000000001.md5”

edits：用来记录操作日志，以在文件尾部追加内容的形式记录操作。记录内存中最新的操作，2NN会将edits的操作应用到fsimage中，更新fasimage的内容。edits也是在磁盘上，形如“edits_000000000000000001-000000000000000002”。

edits、fsimage文件路径：NN（namenode）节点中的 /opt/module/hadoop-3.x.x/data/dfs/name/current；2NN（secondarynamenode）节点中的 /opt/module/hadoop-3.x.x/data/dfs/name/current。

两者的edits差一个edits_inprogress文件。

元数据的拷贝流程

整个流程涉及到三个主体：Client、NameNode’、SecondaryNameNode，其中主要是NameNode和SecondaryNameNode之间的交互。

NN会在内存中维持着实时的元数据信息，内存通常为128GB，其中每个Block占元数据150字节。

具体流程如下：

①NN开机时会加载fsimage和edits_inprogress_001到内存中，在fsimage中执行相应操作（也称为合并）后记录在内存中。（比如说fsimage文件名为fsimage_000000000000000124。则表示包括edits_000000000000000124文件和之前小于124的edits都已经合并完毕，所以开机时只需要从编号为125的edits开始合并。）

②Client发来元数据的增删改请求，此时NN会在edits_inprogress_001中记录操作日志。此时edits_progress_001文件会越来越大。这个时候2NN的作用就出现了，2NN负责fsimage和edits的合并，见下面流程。

③2NN会对NN发起询问，问是否需要CheckPoint服务，有两个触发条件（1）2NN会定时的对NN执行CheckPoint；（2）NN中的Edits的数据满了。当满足其中一个，2NN就会对NN发起CheckPoint的执行请求。

④NN收到执行请求后会新建一个新文件edits_inprogress_002，这个文件是新的操作日志，NN会用这个新文件记录接下来的操作，与此同时，NN会将原来的edits（edits_inprogress_001）重命名为edits_001（也就是去掉了inprogress），这套操作也可以叫“滚动正在写的edits”。而此时fsimage还没有执行edits_001的操作，换句话说就是fsimage还没有与edits_001合并，而这个合并操作接下来会交给2NN处理。

⑤2NN将当前NN磁盘中的fsimage和刚刚重命名完毕的edits_001这两者拷贝到2NN的磁盘中，2NN此时会在自己的主机上将两者从磁盘加载到自己的内存中，并加以合并。合并后，会生成一个新的文件fsimage.chkpoint（其文件名为fsimage.chkpoint，是更新后的fsimage）。

⑥2NN此时再将fsimage.chkpoint拷贝到NN的磁盘中，并将其重命名为fsimage（与原来一样，也就是说覆盖了原来的fsimage），至此就完成了一次拷贝工作。

指令

查看fsimage文件需要进行转换，否则乱码，转换指令如下，在current文件夹下：

#hdfs oiv -p 【输出的文件类型】 -i 【要查看的fsimage文件】 -o 【转换后文件输出路径】
hdfs oiv -p XML -i fsimage_0000000000000000870 -o /tmp/fsimage.xml

查看edits文件：

#hdfs oev -p 【输出的文件类型】 -i 【要查看的edits文件】 -o 【转换后文件输出路径】
hdfs oev -p XML -i edits_nprogress_0000000000000003105 -o /tmp/edits.xml

（在企业中往往使用的是高可用，也就是两个NN，而不是采用NN加2NN的形式。）