Namenode 与 SecondaryNameNode

1、HDFS元数据管理机制

问题1：NameNode如何管理和存储元数据？

计算机中存储数据两种：内存或者是磁盘
元数据存储磁盘：存储磁盘无法面对客户端对元数据信息的任意的快速低延迟的响应，但是安全性高
元数据存储内存：元数据存放内存，可以高效的查询以及快速响应客户端的查询请求，数据保存在内存，如果断点，内存中的数据全部丢失。

解决方案：内存+磁盘；NameNode内存+FsImage的文件（磁盘）

新问题：磁盘和内存中元数据如何划分？

两个数据一模一样，还是两个数据合并到一起才是一份完整的数据呢？

一模一样：client如果对元数据进行增删改操作，需要保证两个数据的一致性。FsImage文件操作起来效率也不高。
两个合并=完整数据：NameNode引入了一个edits文件（日志文件：只能追加写入）edits文件记录的是client的增删改操作，不再选择让NameNode把数据dump出来形成FsImage文件（这种操作是比较消耗资源）。

元数据管理流程图

第一阶段：NameNode启动

第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
客户端对元数据进行增删改的请求。
NameNode记录操作日志，更新滚动日志。
NameNode在内存中对数据进行增删改。

第二阶段：Secondary NameNode工作

Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否执行检查点操作结果。
Secondary NameNode请求执行CheckPoint。
NameNode滚动正在写的Edits日志。
将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
生成新的镜像文件fsimage.chkpoint。
拷贝fsimage.chkpoint到NameNode。
NameNode将fsimage.chkpoint重新命名成fsimage。

2、Fsimage与Edits文件解析

NameNode在执行格式化之后，会在/opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current目录下产生如下文件

Fsimage文件：是namenode中关于元数据的镜像，一般称为检查点，这里包含了HDFS文件系统所有目录以及文件相关信息（Block数量，副本数量，权限等信息）
Edits文件：存储了客户端对HDFS文件系统所有的更新操作记录，Client对HDFS文件系统所有的更新操作都会被记录到Edits文件中（不包括查询操作）
seen_txid：该文件是保存了一个数字，数字对应着最后一个Edits文件名的数字
VERSION：该文件记录namenode的一些版本号信息，比如：CusterId,namespaceID等

（1） Fsimage文件内容

官方地址

https://hadoop.apache.org/docs/r2.9.2/hadoop-project-dist/hadoophdfs/HdfsImageViewer.html

因为Fsimg中保存的内容是二进制数据，我们必须通过工具将他进行转化后才能阅读

查看oiv和oev命令

基本语法

hdfs oiv -p 文件类型(xml) -i 镜像文件 -o 转换后文件输出路径

案例实操

[root@linux121 current]$ cd /opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current

[root@linux121 current]$ hdfs oiv -p XML -i fsimage_0000000000000000265 -o
/opt/lagou/servers/fsimage.xml

[root@linux121 current]$ cat /opt/lagou/servers/fsimage.xml

这样我们打开xml文件就能阅读其内容

问题：Fsimage中为什么没有记录块所对应DataNode？

在内存元数据中是有记录块所对应的dn信息，但是fsimage中就剔除了这个信息；HDFS集群在启动的时候会加载image以及edits文件，block对应的dn信息都没有记录，集群启动时会有一个安全模式（safemode）,安全模式就是为了让dn汇报自己当前所持有的block信息给nn来补全元数据。后续每隔一段时间dn都要汇报自己持有的block信息。

（2）Edits文件内容

基本语法

hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径

案例实操

[root@linux121 current]$ hdfs oev -p XML -i edits_0000000000000000266-0000000000000000267 -o /opt/lagou/servers/hadoop-2.9.2/edits.xml

[root@linux121 current]$ cat /opt/lagou/servers/hadoop-2.9.2/edits.xml

备注：Edits中只记录了更新相关的操作，查询或者下载文件并不会记录在内！！

问题：NameNode启动时如何确定加载哪些Edits文件呢？

nn启动时需要加载fsimage文件以及那些没有被2nn进行合并的edits文件，nn如何判断哪些edits已经被合并了呢？

可以通过fsimage文件自身的编号来确定哪些已经被合并。

（3） checkpoint周期

[hdfs-default.xml]

<!-- 定时一小时 -->
<property><name>dfs.namenode.checkpoint.period</name><value>3600</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>60</value><description> 1分钟检查一次操作次数</description>
</property >

3、NameNode故障处理

NameNode故障后，HDFS集群就无法正常工作，因为HDFS文件系统的元数据需要由NameNode来管理维护并与Client交互，如果元数据出现损坏和丢失同样会导致NameNode无法正常工作进而HDFS文件系统无法正常对外提供服务。

如果元数据出现丢失损坏如何恢复呢？

将2NN的元数据拷贝到NN的节点下（此种方式会存在元数据的丢失。）
搭建HDFS的HA（高可用）集群，解决NN的单点故障问题！！（借助Zookeeper实现HA，一个Active的NameNode,一个是Standby的NameNode）