Hadoop 3.x|第六天|NameNode和SecondaryNameNode

NameNode

内存与磁盘数据存储位置 fsImage和Edits的合并（引入2NN）

流程fsImage和Edits的位置 NN和2NN工作机制

第一阶段：NN工作第二阶段：2NN工作 Fsimage和Edits

定义工作查看fsImage文件命令查看Edits文件命令 检查点CheckPoint

如果存储在内存，好处是计算快，坏处是可靠性差，一旦断电，元数据丢失，整个集群就无法工作。
如果存储在磁盘，好处是可靠性高，坏处是计算慢，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低

NN把数据存储在内存+磁盘里，磁盘里一般使用fsImage存储数据，Edits用来追加记录。

当在内存中的元数据更新时，如果同时更新 FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入 Edits 文件（只进行追加操作，效率很高）。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到
Edits 中。这样，一旦 NameNode 节点断电，可以通过 FsImage 和 Edits 的合并，合成元数据。如果长时间添加数据到 Edits 中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage 和 Edits 的合并。因此，引入一个新的节点SecondaryNamenode，专门用于 FsImage和 Edits 的合并。

这个是DataNode里Edits和fsImage位置
这个是2NN里Edits和fsImage位置

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

2NN询问NNN是否需要 CheckPoint（定时时间到或者Edits中数据满了）

如果NN允许，那么2NN 请求执行 CheckPoint。

NN滚动正在写的 Edits 日志，创建一个Edits副本（inprogress）作为新的日志，并将之前的Edits改名。


将改名之后的编辑日志和镜像文件拷贝到 2NN。

Secondary NN加载编辑日志和镜像文件到内存，并合并生成新的镜像文件 fsimage.chkpoint。

拷贝 fsimage.chkpoint 到 NN。

NN将 fsimage.chkpoint 重新命名（覆盖）成 fsimage。

Fsimage是HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件inode的序列化信息。
Edits文件存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到Edits文件中。
seen_txid文件保存的是一个数字，就是最后一个edits_的数字

每次NameNode启动的时候都会将Fsimage文件读入内存，加载Edits里面的更新操作，保证内存中的元数据信息是最新的、同步的。
可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并。

基本语法

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

实际执行：-p 指的是以什么格式保存，-i指定文件，-o输出文件存放目录

hdfs oiv -p XML -i fsimage_0000000000000000414 -o /opt/module/hadoop-3.1.3/fsimage.xml

基本语法

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

应用场景

hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-3.1.3/edits.xml

通常每隔一个小时检查一次，在hdfs-default.xml里

 dfs.namenode.checkpoint.period
 3600s

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