Namenode和SecondaryNamenode

Namenode和SecondaryNamenode

NN和2NN工作机制

思考：namenode中元数据是储存在哪里的？

​ 首先我们做一个假设，如果储存在namenode节点的磁盘，因为需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只是存在内存中，一旦发生断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的fsimage。

​ 这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新fsimage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦namenode节点断电，就会产生数据丢失。因此，引入edits文件（只进行追加操作，效率很高）。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到edits中。这样，一旦namenode节点断电，可以通过fsimage和edite的合并，合并元数据。

元数据合并的原理

1. namenode在启动的时候，第一步就加载fsimage

2. 第二步就会加载上次未合并的数据edits，当都加载完成，就达到上次nn关闭的状态

3. client对namenode发起增删改请求时，会先将数据操作记录到edits，然后再讲这些操作加载到内存

4. 2nn每隔一段时间会向nn发起请求checkpoint（是否需要合并数据）

   • checkpoint触发条件：配置hdfs.site.xml文件

     • 定时时间到（通常1小时）

       <property>
       	<name>dfs.namenode.checkpoint.period</name>
       	<value>3600</value>
       </property>
       

     • edites中数据满了

       <-操作次数触发checkpoint->
       <property>
       	<name>dfs.namenode.checkpoint.txns</name>
       	<value>1000000</value>
       </property>
       <-询问nn间隔时间，单位：秒->
       <property>
       	<name>dfs.namenode.checkpoint.check。period</name>
       	<value>60</value>
       </property>
       

     • 每当namenode刚启动也会checkpoint：
       

5. 如果需要checkpoint，nn会创建一个新的edits来记录操作，将之前的edits和fsimage交给2nn

6. 2nn以同样的操作将两文件数据加载到内存，然后合并成新的fsimage，并送还给nn，这样就完成了元数据合并
   注意：nn与2nn的内存状态是不一样的，区别在于nn有最新的edits，如果不需要checkpoint，2nn就没有这个文件，所以当nn挂掉2nn不可以贸然顶替，由此可以判断：2nn只是辅助nn操作并不可以成为nn的热备