NN和2NN的工作机制
思考：NameNode中的元数据存储在哪
首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户端请求，必然是效率过低，因此，原数据需要放在内存中。但如果只存在内存中，假如宕机、断电，元数据丢失，整个集群就无法工作了，因此产生在磁盘中备份元数据的FsImage
这样又会带来新的问题，当内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性的问题，一旦NameNode节点宕机，就会产生数据丢失。因此，引入Edits文件，只进行追加，效率很高。每当元数据有更新时，修改内存中的元数据并追加到Edits文件中。这样一旦NameNode节点宕机，可以通过FsImage和Edits合并，合成元数据
但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦宕机，恢复元数据需要的时间更长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode进行，又会降低效率，因此引入了SecondaryNameNode，专门用于FsImage和Edits的合并
NameNode工作机制
image.png
第一阶段：NameNode启动
- 第一次启动NameNode格式化后，创建FsImage和Edits文件。如果不是第一次启动，直接加载Edits和FsImage到内存
- 客户端对元数据进行增删改的操作
- NameNode记录操作日志，更新滚动日志
- NameNode在内存中对元数据进行修改
第二阶段：SecondaryNameNode工作
- SencondaryNameNode询问NameNode是否需要CheckPoint。直接带回NameNode的检查结果
- SecondaryNameNode请求执行CheckPoint
- NameNode滚动正在写的Edits日志
- 将滚动前的编辑日志和镜像文件拷贝回SecondaryNameNode
- SecondaryNameNode加载编辑日志和镜像文件到内存，进行合并
- 生成新的镜像文件fsimage.chkpoint
- 拷贝fsimage.chkpoint到NameNode
- NameNode将fsimage.chkpoint重命名为fsimage
FsImage和Edits解析
NameNode被格式化之后，将会在data/tmp/dfs/name/current目录中产生如下文件
image.png
- fsimage文件：HDFS文件系统元数据的一个永久性检查点，其中包含HDFS文件系统的所有目录和文件inode的序列化信息
- Edits文件：存放HDFS文件系统的所有更新操作路径，文件系统客户端执行的所有写操作首先会被记录到Edits文件中
- seen_txid：保存的是一个数字，就是最后一个edits的数字
- VERSION，记录命名空间ID和集群ID
oiv查看fsimage文件
基本语法：
hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
oev查看edits文件
基本语法
hdfs oev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径
CheckPoint时间设置
1、默认情况下每个一小时执行一次
image.png
2、一分钟检查一次操作次数，当操作次数达到一百万次，执行一次
image.png
