SecondaryNamenode与持久化

SecondaryNamenode—持久化

内存和磁盘

内存: 容量小，价格高，速度快
磁盘: 容量大，价格低，速度慢
当设备断电时，内存中的数据会被释放掉，如果没有保存到磁盘上，将会造成损失
比如编写的文档没有保存，突然断电，之前未保存的作业会消失。

Hadoop集群的持久化

NN(NameNode)掌握一批元数据 为了数据的安全需要将数据写到磁盘上 这种操作称为持久化
但是NN不做持久化这件事，他交给 SecondaryNamenode去做
NN不能做持久化的原因
1. NN本身工作较多，如果在进行持久化操作，容易宕机。
2. 可以做需求小，占用内存少，不影响计算效率的持久化。

元数据:描述数据的数据，一种电子目录，记录数据的文件位置、历史数据等信息。
持久化:将内存中的数据，保存到硬盘(磁盘)中，把数据持久保存。

当集群因断电等特殊原因产生数据丢失时，为了恢复之前内存中的数据NN回去磁盘上读取元数据，恢复到断电前的状态，大大的减少损失。

SNN永远不能取代NN的位置，SNN只是负责持久化！！！他只是NN的一个热备

NN与SNN的工作机制

第一次启动NameNode格式化后，创建edits.log和fsimage文件。
如果不是第一次启动，直接加载编辑日志(edits.log)和镜像文件(fsimage)到内存。

edits 存储的是在运行过程中产生的操作信息
fsimage namenode的元数据镜像文件，保存在磁盘

达到一定条件时NN会把edits.log和fsimage文件发送给SNN，SNN会进行打包合成为新的fsimage并且将合成后的fsimage写入到磁盘中
NN会把新的fsimage拿回来，和新产生的edits.log在次发送给SNN进行打包。。。。循环往复达到持续持久化的目的

持久化触发条件(NN向SNN发送edits.log和fsimage):

1. 超过3600s
2. edits.log的大小超过64M时

注意:当SNN在合并edits.log和fsimage时，NN中的edits.log在次达到了持久化触发条件，这个时候有两种情况

1. 个别现象:NN另外再启动一个edits.log NN中会有两个e1和e2，SNN会优先合并1在合并2
2. 普遍显现: 如果经常出现这种等待的情况，就需要对集群进行优化，调整 edits.log的大小

安全机制

当遇到重复的断电，或是NN多次挂掉的情况
安全模式:
1. 恢复系统状态
2. 检查DN的信息
3. 对有问题的DN进行修复

出现的问题三种情况
1.在传输过程中断电        ---数据丢失，无法找回	
  如果数据特别重要，只能提前做出预判，调整集群，减小损失。
2.传输完成后断电
  当集群重新恢复后，NN会到磁盘上去读取元数据，对状态进行恢复，不影响已经传输完的数据
3.在DN出现问题
  DN出现问题后client将不再向这个DN发送信息，而是选择其他DN。	
  在DN恢复后，如果有新的任务，根据情况，确定是否将新的文件上传

NN与DN之间的通信是采用一种心跳机制，DN每隔一定时间向NN发送数据，证明自己还活着。。

总结:集群内的持久化就是把NN的元数据交给SNN存储到磁盘上，当断电或是NN挂掉后，可以取磁盘读取元数据，恢复集群的状态

意为自己学习参考，如果有帮到您的地方，不胜荣幸！