SecondaryNamenode-----持久化

**前言**

最近刚接触Hadoop,一直没弄明白NameNode和Secondary NameNode的关系。最初一开始以为Secondary NameNode是NameNode的备份,为了防止NameNode的单点失败的.但其实并不是这样的！

场景模拟: 我们的计算机在工作的时候,突然出现宕机的情况?请问原来计算的任务是否会被保存?怎么回复到原来的状态,中间的保存的操作是如何完成的…让我们一起来探索一下把！

正文
1 NameNode
NameNode主要是保存HDFS元数据的信息,将这些元信息保存在内存当 中 。当然这些信息也是可以存入到硬盘当中去的。
*元数据:描述数据的数据

(侵删)

Ques1:内存中的数据存入到磁盘?

为了保证元数据的安全,将内存中的数据放到磁盘中（持久化操作）

edits:计算器启动后,保存计算机操作的记录,如果我的计算机一直处于开机状态,没有对它进行任何操作他也会进行保存.（存放在系统在运行过程中产生的操作信息）
edits延申: 客户端对HDFS的文件系统目录树进行的任何修改，都会被记录到编辑日志（edits）文件中，以保证系统出现故障后，能够根据这些日志进行恢复，但是随着日志不断地增加，这意味着系统重启后，需要进行恢复的时间也就越长。为了避免这一情况的发生，HDFS引入了检查点（checkpoint）机制。

fsimage:计算机启动后,保存计算机的日志
fsimage延申 命名空间镜像(FSImage)文件是系统的持久性检查点，和编辑日志不同，它不能在客户端做的每次修改后都及时更新。故命名空间镜像再加上编辑日志，NameNode节点的元数据提供了安全保障。

2.如何触发持久化操作

       1.时间:超过3600s也就是1个小时 
       2.大小超过64M         
       问题演变:如果我每隔3秒产生的数据大于64M我会怎么处理呢?
       答: 同样也会进行持久化操作 ,触发持久化机制就是将NameNode的元数据写入到磁盘当中去进行存储。如果我们的NameNode宕机后就会去磁盘进行读取上一次我存入磁盘当中的合成的新文件,回复之前的状态。

3.持久化磁盘遇到问题
　1.当我们的edit和fsimage在和并的过程当中，NameNode下的edit文件变得越来越大?怎么处理？？
　

1. 1.如果是出现个别的情况,我们的edit和fsimage进行合并的过程当中，edit如果单方面大于64M。这时候里面出现两个edit来完成日志的存储,合成的文件首先会考虑和第一个edit文件进行合并,合并完成后再会和第二个edit进行合并;
   2如果这个问题是常态,不仅仅是这一个有问题的话，我们此刻就要需要对集群进行一个调整,调整成64M 128M(通常来说这是一个数据调优的过程,如果edit文件还是会变得很大,也许是我们集群在某些地方搭建的问题)
   引入案例:我们都知道淘宝双十一的活动,在每一刻的流量就会非常大,那么它是对数据进行怎样的处理?我们在网页浏览商品的同时加载出很多信息比如某件商品的图片和信息等等,那么面对于这么庞大的信息集体,我们要存储并不是这些,我们会保留一些相对来说重要的信息,也许是1TB当中只有几kb是我们想要的数据…

5.心跳机制
NN和DN的通讯机制: 每隔3s,DN会向NN发送一次心跳,如果我在一分钟没有做出心跳回应那么我会认为DN已经挂掉
安全模式:

2. 1.恢复系统状态
   如果出现停电的情况下,那么我在一次进行重启启动的时候,获取读去磁盘存储的数据,完成数据的回复
   2.检查DN的信息（稍后整理）

   ---

   
   3.有问题的DN进行修复

情景如下:

3. 3.1 传输的过程出现问题?如果我在数据传输的时候出现停电的情况,会导致数据丢失的情况,在考虑这一问题的情况下，我们会提前对这一类问题进行提前预测,来弥补这个数据丢失的后果。
   考虑到是重要数据，只能通过预判来进行对数据进行相应的调整。
   3.2 持久化后考虑到停电的问题,在我下一次启动NameNode的时候我考虑到我是否能够正确读取数据
   3.3 任务的上传:如我的备份节点出现问题根据情况而做出确定是否新的文件进行上传 上传block的时候DN3会出现挂掉的情况,当前任务不会再出现上传,当DN3回复之后,相当于一个新的节点…

Tips：
1.上文是自己对Secondary的梳理与理解在某些方面考虑的不是特别成熟和分析的不到位，请各位指正
2.发表博客是为了让自己有一个和大家分享知识的机会，能够互相学习和彼此收益

---

参考地址:https://www.cnblogs.com/smartloli/p/4342340.html