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):
- 超过3600s
- edits.log的大小超过64M时
注意:当SNN在合并edits.log和fsimage时,NN中的edits.log在次达到了持久化触发条件,这个时候有两种情况
- 个别现象:NN另外再启动一个edits.log NN中会有两个e1和e2,SNN会优先合并1在合并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挂掉后,可以取磁盘读取元数据,恢复集群的状态
意为自己学习参考,如果有帮到您的地方,不胜荣幸!