hdfs故障恢复及原理

2NN工作机制

Fsimage：hdfs文件系统元数据的一个永久性检查点。

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

1. NameNode启动，滚动Edits并生成一个空的edits.inprogress，并加载Edits和Fsimage到内存中，持有最新的元数据信息。
2. Client开始对NameNode发送元数据的增删改的请求，这些请求的操作首先会被记录到edits.inprogress中（查询操作不会被记录，因为查询操作不会更改元数据信息），如果此时NameNode挂掉，重启后会从Edits中读取元数据的信息并在内存中执行元数据的增删改的操作。
3. SecondaryNameNode询问NameNode是否需要CheckPoint（触发CheckPoint需要满足两个条件中的任意一个，定时时间到和Edits中数据写满了）。
4. SecondaryNameNode执行CheckPoint，NameNode滚动Edits并生成一个新的edits.inprogress并将以后所有新的操作都写入edits.inprogress
5. 其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地，然后将拷贝的Edits和Fsimage加载到内存中进行合并，生成fsimage.chkpoint
6. 然后将fsimage.chkpoint拷贝给NameNode，重命名为Fsimage后替换掉原来的Fsimage。
7. NameNode在启动时就只需要加载新的edits.inprogress和新Fsimage即可，因为合并过的Edits中的元数据信息已经被记录在Fsimage中。

CheckPoint时间设置

• 通常情况下，SecondaryNameNode每隔一小时执行一次 [hdfs-default.xml] 。

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

• 一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。

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

NameNode故障处理

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

• 将SecondaryNameNode中数据拷贝到NameNode存储数据的目录
• 使用-importCheckpoint选项启动NameNode守护进程，从而将SecondaryNameNode中数据拷贝到NameNode目录中。

Hadoop宕机

• 如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物理内存量，默认是8192MB）
• 如果写入文件过快造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。例如，可以调整Flume每批次拉取数据量的大小参数batchsize。

Donate