hdfs之NameNode和SecondaryNameNode

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中。

Fsimage和Edits解析

oiv查看Fsimage文件

hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-2.7.2/fsimage.xml

cat /opt/module/hadoop-2.7.2/fsimage.xml

oev查看Edits文件

hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-2.7.2/edits.xml

cat /opt/module/hadoop-2.7.2/edits.xml

CheckPoint

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

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

2. 一分钟检查一次操作次数，3当操作次数达到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存储数据的目录；

1. kill -9 NameNode进程
2. 删除NameNode存储的数据（/opt/module/hadoop-2.7.2/data/tmp/dfs/name）

rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*

3. 拷贝SecondaryNameNode中数据到原NameNode存储数据目录

scp -r atguigu@hadoop104:/opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/* ./name/

4. 重新启动NameNode

 sbin/hadoop-daemon.sh start namenode

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

1. 修改hdfs-site.xml中的

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

<property>
  <name>dfs.namenode.name.dir</name>
  <value>/opt/module/hadoop-2.7.2/data/tmp/dfs/name</value>
</property>

2. kill -9 NameNode进程
3. 删除NameNode存储的数据（/opt/module/hadoop-2.7.2/data/tmp/dfs/name）

rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*

4. 如果SecondaryNameNode不和NameNode在一个主机节点上，需要将SecondaryNameNode存储数据的目录拷贝到NameNode存储数据的平级目录，并删除in_use.lock文件

scp -r atguigu@hadoop104:/opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary ./


rm -rf in_use.lock

pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs

ls
data  name  namesecondary

5. 导入检查点数据（等待一会ctrl+c结束掉）

 bin/hdfs namenode -importCheckpoint

6. 启动NameNode

 sbin/hadoop-daemon.sh start namenode

集群安全模式

命令

bin/hdfs dfsadmin -safemode get		（功能描述：查看安全模式状态）
bin/hdfs dfsadmin -safemode enter  	（功能描述：进入安全模式状态）
bin/hdfs dfsadmin -safemode leave	（功能描述：离开安全模式状态）
bin/hdfs dfsadmin -safemode wait	（功能描述：等待安全模式状态）

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

安全模式特点

1. 分布式文件系统处于安全性安全模式下,文件系统中的内容不许与被修改和删除
2. 主要是为了系统启动时检查各个DateNode数据块的有效性,同时根据策略必要的复制或者删除部分数据块
3. 正常情况下,安全模式会运行一段时间后自动退出，也可以使用命令: hadoop fs –safemode leave 离开安全模式状态