SecondaryNamenode二次节点持久化

SecondaryNamenode

SecondaryNamenode是一个二次节点，相当于公司的副总

主节点掌握一批元数据
为了保证数据的安全—将内存中的数据存放在磁盘中

在此介绍下
硬盘 内存大 便宜 还慢
内存 内存小 贵 还快

问题
当我们的集群因断电等特殊原因使得一些数据丢失怎么解决

首先说下为什么主节点不能做持久化的原因
可以做：需求小、占用内存小、不影响计算xiaol
不可以做 主节点（Namenode） 本身工作已经很多 有可能在做持久化的时候宕机

注意：SecondaryNamenode永远无法替代Namenode的位置，他只是Namenode的一个热备

Namenode和SecondaryNamenode的执行方式

Namenode 在和 SecondaryNamenode交互式会形成两个组件

edits
存放系统在运行过程中产生的操作信息
faimage
是在系统运行中不断产生的日志信息镜像两个组件回到二次节点中形成一个新的fsimage,由二次节点SecondaryNamenode存到硬盘中等出现 问题时想要恢复状态直接就从硬盘中获取就行；

**持久化的触发条件**

当edits超过3600S或者edits的大小超过64兆的时候（数据不是死的都可以调）

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

**断电问题**
 持久化之前  -----再次启动，读取系统日志
 持久化之后  -----读取磁盘中的数据，恢复状态
 
 **重复的断电**
主节点Namenode和从节点Datanode的通信级制--------心跳机制（每隔3S，从节点Datanode会向主节点Namenode发送一次心跳  1分钟没有心跳，则认为从节点Datanode从节点直接消失）

问题来了

在进行合并的时候形成新的fsimage，这时还没传送至主节点Namenode时edits又满64兆那怎么解决？
此图比较抽象哈哈哈

1、 个别现象另外在启动一个edits里面会同时存在两个edits
fsimage会先和最近edits进行合并，然后在合并其它的
2、常态
就需要对集群进行调整，调大edits的大小

下面讲一下我们的安全模式

1. 恢复系统的状态

2. 检查从节点Datanode的信息

3. 有问题的从节点Datanode进行修复
   1.在传输过程中断电 —数据丢失如果数据特别重要，那只能提前进行调优进行相应的调整
   2.传输完成之后断电
   当我的集群重新恢复之后，主节点Namenode会去读取元数据，对状态进行相应的恢复
   3.若从节点Datanode出现问题

   在从节点Datanode恢复之后，如果有新的任务，根据情况，确定是否将新的文件上传备份机制会去查找断电之前的数据