Hadoop之SecondaryNameNode

一 、SecondaryNameNode的作用

SecondaryNameNode的作用是合并fsimage和edits文件。

NameNode的存储目录树的信息，而目录树的信息则存放在fsimage文件中，当NameNode启动的时候会首先读取整个fsimage文件，将信息装载到内存中。
Edits文件存储日志信息，在NameNode上所有对目录的操作，增加，删除，修改等都会保存到edits文件中，并不会同步到fsimage中，当NameNode关闭的时候，也不会将fsimage和edits进行合并。
所以当NameNode启动的时候，首先装载fsimage文件，然后按照edits中的记录执行一遍所有记录的操作，最后把信息的目录树写入fsimage中，并删掉edits文件，重新启用新的edits文件。
这个过程可以在打开dfs网页端口50070，可以看到：

在这里插入图片描述

在这里插入图片描述

二、 SecondaryNameNode出现的原因

但是如果NameNode执行了很多操作的话，就会导致edits文件会很大，那么在下一次启动的过程中，就会导致NameNode的启动速度很慢，慢到几个小时也不是不可能，所以出现了SecondNameNode。

三、 SecondaryNameNode唤醒合并的规则

SecondaryNameNode 会按照一定的规则被唤醒，进行fsimage和edits的合并，防止文件过大。
合并的过程是，将NameNode的fsimage和edits下载到SecondryNameNode 所在的节点的数据目录，然后合并到fsimage文件，最后上传到NameNode节点。合并的过程中不影响NameNode节点的操作
SecondaryNameNode被唤醒的条件可以在Core-site.xml中配置：
fs.checkpoint.period：单位秒，默认值3600，检查点的间隔时间，当距离上次检查点执行超过该时间后启动检查点
fs.checkpoint.size：单位字节，默认值67108864，当edits文件超过该大小后，启动检查点
SecondaryNameNode一般处于休眠状态，当两个检查点满足一个，即唤醒SecondaryNameNode执行合并过程。

在分布式的环境中： fsimage和edits存放时在 你在core-site.xml中配置的目录之下，比如{hadoop.tmp.dir}/tmp/dfs/name/current
其中： edits_inprogress_0000000000000003317 带有inprogress的文件是正在操作的日志文件，不参与当前的合并。

四、查看fsimage文件和edits日志文件

edits文件和fsimage文件是二进制格式保存的，不能直接查看，当然提供了hdfs提供了工具查看这两个文件：

edits文件的查看，需要借助工具的帮助转换成xml文件才可查看，例如： hdfs oev -i edits_inprogress_0000000000000003317 -o ~/temp/inprogress.xml 将edits文件转为了xml文件，用vi编辑器查看即可
查看fsimage的方法类似，使用命令oiv : hdfs oiv -i fsimage_0000000000000003314 -o ~/temp/fsimage.xml

五、配置单独节点上的SecondaryNameNode

分布式中SecondaryNameNode 默认和NameNode在一个节点上，但是可以配置成单独的节点：

1. 需要新增master文件
2. master文件中存放SecondNameNode的节点的IP地址
3. 修改hdfs-site.xml 文件：

dfs.http.address
master:50070 这个是主节点的地址与端口





dfs.namenode.secondary.http-address
slave1:50090 这个是SecondNameNode的地址与通信端口

每个节点都要修改，重启集群即可！

欢迎关注我的微信公众号，共同进步。

在这里插入图片描述