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恢复之后,如果新的任务,根据情况,确定是否将新的文件上传