Secondary NameNode

Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点
NN掌握一批元数据
为了保证元数据的安全，将内存中的数据存放在磁盘中
持久化：
当我们的集群因断电等待特殊原因产生问题的时候，问题解决，重新开机，会去磁盘上读取元数据，恢复到断电前的状态

NN不能进行持久化的 原因：
其实他可以做因为需求小，占用内存少，不影响计算效率
不可以做的原因是：NN本身工作已经很多了，有可能在持久化的过程中宕机

备注：SNN永远无法取代NN的位置，他只是NN的一个热备

NN中有edits.log 和 fsimace
edits 是存放系统在运行过程中产生的操作信息
fsimage即元数据镜像文件
当做持久化时，edits.log和fsimage会被SNN吸到磁盘中形成一个新的fsimage1,NN在运行操作的过程中会产生一个新的edits1,这个时候他会把新的fsimage1传给NN，在NN中edits1会和fsimage1重新结合，在通过SNN发送到磁盘中

例如下图所示

1.SecondaryNameNode通知NameNode准备提交edits文件，此时主节点产生edits1
2.SecondaryNameNode通过http get方式获取NameNode的fsimage与edits.log文件（在SecondaryNameNode的current同级目录下可见到temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）
3.SecondaryNameNode开始合并获取的上述两个文件，产生一个新的f1文件
4.SecondaryNameNode用http post方式发送f1至NameNode
5.NameNode将f1与edits1再按上述重复操作

持久化的触发条件：
超过3600s或者edits的大小超过64M

在上图所示，就是在触发条件满足的情况下发生的
当SNN合并的时候，edits又超过64M，我们应该怎么做

此时分两种情况解决
1）个别现象，另外在启动一个edits,里面会同时存在两个edits.例如edits1,edits2.此时fsimage会和第一个edits1进行结合，然后在和edits2合并
2） 当常态时，就需要对集群进行调整，调整edits的大小，列如把64M改成128M

总结：持久化是不是就是将NN的元数据写入到磁盘中进行存储，当NN挂了之后重启的时候回去磁盘读取相应的元数据，恢复集群的状态—（内存断电丢失）

断电
持久化之前 — 再次启动，读取系统日志
持久化之后 — 读取磁盘中的数据，恢复状态
NN和DN 的通信机制是由心跳机制实现（每隔3S，DN会向NN发送一次心跳，当1分钟没有心跳，则认为DN挂掉）

安全模式：
1.恢复系统状态
2.检查DN的信息
3.有问题的DN进行修复
1）在传输的过程中断电 —数据丢失
如果数据特别重要，那只能提前进行预判进行相应的调整
2）传输完成之后断电
当我的集群重新恢复之后，NN会去读取元数据，对状态进行相应的恢复
3）若DN出现问题
在DN恢复之后，如果新的任务，根据情况，确定是否将新的文件上传