一 、SecondaryNameNode的作用
SecondaryNameNode的作用是合并fsimage和edits文件。
NameNode的存储目录树的信息，而目录树的信息则存放在fsimage文件中，当NameNode启动的时候会首先读取整个fsimage文件，将信息装载到内存中。
Edits文件存储日志信息，在NameNode上所有对目录的操作，增加，删除，修改等都会保存到edits文件中，并不会同步到fsimage中，当NameNode关闭的时候，也不会将fsimage和edits进行合并。
所以当NameNode启动的时候，首先装载fsimage文件，然后按照edits中的记录执行一遍所有记录的操作，最后把信息的目录树写入fsimage中，并删掉edits文件，重新启用新的edits文件。
这个过程可以在打开dfs网页端口50070，可以看到：
<figcaption style="line-height: inherit; margin: 0px; padding: 0px; margin-top: 10px; text-align: center; color: rgb(153, 153, 153); font-size: 0.7em;">在这里插入图片描述</figcaption>
二、 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在一个节点上，但是可以配置成单独的节点：
- 需要新增master文件
- master文件中存放SecondNameNode的节点的IP地址
- 修改hdfs-site.xml 文件：
<property>
<name>dfs.http.address</name>
<value>master:50070</value> 这个是主节点的地址与端口
<description>
</description>
</property>
<property>
<name>dfs.namenode.secondary.http-address</name>
<value>slave1:50090</value> 这个是SecondNameNode的地址与通信端口
</property>
每个节点都要修改，重启集群即可！
欢迎关注我的微信公众号，共同进步。
