【Hadoop学习之HDFS】_11HDFS之NN和2NN

一、NN与2NN的工作机制

Fsimage：NameNode内存中元数据序列化后形成的文件。

Edits：记录客户端更新元数据信息的每一步操作（可通过Edits运算出元数据）。

NameNode启动时，先滚动Edits并生成一个空的edits.inprogress，然后加载Edits和Fsimage到内存中，此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求，这些请求的操作首先会被记录到edits.inprogress中（查询元数据的操作不会被记录在Edits中，因为查询操作不会更改元数据信息），如果此时NameNode挂掉，重启后会从Edits中读取元数据的信息。然后，NameNode会在内存中执行元数据的增删改的操作。

由于Edits中记录的操作会越来越多，Edits文件会越来越大，导致NameNode在启动加载Edits时会很慢，所以需要对Edits和Fsimage进行合并（所谓合并，就是将Edits和Fsimage加载到内存中，照着Edits中的操作一步步执行，最终形成新的Fsimage）。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。

SecondaryNameNode首先会询问NameNode是否需要CheckPoint（触发CheckPoint需要满足两个条件中的任意一个，定时时间到和Edits中数据写满了）。直接带回NameNode是否检查结果。SecondaryNameNode执行CheckPoint操作，首先会让NameNode滚动Edits并生成一个空的edits.inprogress，滚动Edits的目的是给Edits打个标记，以后所有新的操作都写入edits.inprogress，其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地，然后将拷贝的Edits和Fsimage加载到内存中进行合并，生成fsimage.chkpoint，然后将fsimage.chkpoint拷贝给NameNode，重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可，因为合并过的Edits中的元数据信息已经被记录在Fsimage中。

1. 第一阶段：NameNode启动

   1. 第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存
   2. 客户端对元数据进行增删改的请求
   3. NameNode记录操作日志，更新滚动日志
   4. NameNode在内存中对数据进行增删改

2. 第二阶段：Secondary NameNode工作

   1. Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果

      CheckPoint触发条件：

      1. 定时时间到了：默认为一小时
      2. Edits中的数据满了：默认为一百万条

   2. Secondary NameNode请求执行CheckPoint

   3. NameNode滚动正在写的Edits日志

   4. 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode

   5. Secondary NameNode加载编辑日志和镜像文件到内存，并合并

   6. 生成新的镜像文件fsimage.chkpoint

   7. 拷贝fsimage.chkpoint到NameNode

   8. NameNode将fsimage.chkpoint重新命名成fsimage

二、FsImage和Edits解析

暂不深入了解

1. 利用ovi命令查看FsImage文件

   # 基本语法
   hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
   

2. 利用oev命令查看Edits文件

   # 基本语法
   hdfs oev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径
   

三、CheckPoint时间设置

1. 通常情况下，SecondaryNameNode每隔一小时执行一次

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

2. 通常情况下，一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次

   <property>
     	<name>dfs.namenode.checkpoint.txns</name>
     	<value>1000000</value>
   	<description>操作动作次数</description>
   </property>
   
   <property>
     	<name>dfs.namenode.checkpoint.check.period</name>
     	<value>60</value>
   	<description>1分钟检查一次操作次数</description>
   </property >
   

四、NameNode故障处理

NameNode故障后，可以采用如下两种方法恢复数据：

方法一：将SecondaryNameNode中数据拷贝到NameNode存储数据的目录

方法二：使用-importCheckpoint选项启动NameNode守护进程，从而将SecondaryNameNode中数据拷贝到NameNode目录中

五、集群安全模式

1. 集群安全模式

   1. NameNode启动：NameNode启动时，首先将镜像文件（FsImage）载入内存，并执行编辑日志（Edits）中的各项操作。一旦在内存中成功建立文件系统元数据的映像，则创建一个新的FsImage文件和一个空的编辑日志。此时，NameNode开始监听DataNode请求。这个过程期间，NameNode一直运行在安全模式，即NameNode的文件系统对于客户端来说是只读的。
   2. DataNode启动：系统中数据块的位置并不是由NameNode维护的，而是以块列表的形式存储在DataNode中。在系统的正常操作期间，NameNode会在内存中保留所有块位置的映射信息。在安全模式下，各个DataNode会向NameNode发送最新的块列表信息，NameNode了解到足够多的块位置信息之后，即可高效运行文件系统。
   3. 安全模式退出判断：如果满足“最小副本条件”，NameNode会在30秒钟之后就退出安全模式。所谓最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别（默认值：dfs.replication.min=1）。在启动一个刚刚格式化的HDFS集群时，因为系统中还没有任何块，所以NameNode不会进入安全模式。

2. 基本语法

   注意：当集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式。

   bin/hdfs dfsadmin -safemode get		# 查看安全模式状态
   bin/hdfs dfsadmin -safemode enter  	# 进入安全模式
   bin/hdfs dfsadmin -safemode leave	# 离开安全模式状态	
   bin/hdfs dfsadmin -safemode wait	# 等待安全模式状态
   
   

六、NameNode多目录配置

1. NameNode的本地目录可以配置成多个，且每个目录存放内容相同，增加可靠性

2. NameNode多目录配置

   1. 在hdfs-site.xml文件中增加如下内容

      <property>
          <name>dfs.namenode.name.dir</name>
      <value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value>
      </property>
      

   2. 停止集群，删除data和logs中所有数据

      rm -rf 文件路径
      

   3. 格式化集群并启动

      bin/hdfs namenode –format
      sbin/start-dfs.sh
      

   4. 查看结果

      ll