三、NameNode工作机制

NameNode & Secondary NameNode工作机制

第一阶段：namenode启动

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

第二阶段：Secondary NameNode工作

• （1）Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。
• （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。

查看SecondaryNameNode信息

• http://192.168.1.103:50090/status.html

chkpoint检查时间参数设置

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

  dfs.namenode.checkpoint.period
  3600

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

  dfs.namenode.checkpoint.txns
  1000000
操作动作次数



  dfs.namenode.checkpoint.check.period
  60
 1分钟检查一次操作次数

镜像文件和编辑日志文件

• namenode被格式化之后，将在 /opt/module/hadoop-2.7.2/data/tmp/dfs/name/current 目录中产生如下文件：

edits_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION

• （1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。
• （2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。
• （3）seen_txid文件保存的是一个数字，就是最后一个edits_的数字
• （4）每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。

oiv查看fsimage文件

• 基本语法：hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
• hdfs oiv -p XML -i fsimage_0000000000000000172 -o ./fsimage_0000000000000000172.xml

oev查看edits文件

• 基本语法：hdfs oev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径
• hdfs oev -p XML -i edits_0000000000000000167-0000000000000000168 -o ./edits_0000000000000000167-0000000000000000168.xml

滚动编辑日志

• 正常情况HDFS文件系统有更新操作时，就会滚动编辑日志。也可以用命令强制滚动编辑日志。
• hdfs dfsadmin -rollEdits

namenode版本号

[hadoop@cmaster0 current]$ pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current
[hadoop@cmaster0 current]$ cat VERSION 
#Tue Dec 25 23:42:03 CST 2018
namespaceID=413226071
clusterID=CID-66e15935-299b-440a-8ae0-30380a092ee1
cTime=0
storageType=NAME_NODE
blockpoolID=BP-2037347169-192.168.1.101-1545339010401
layoutVersion=-63

• （1）namespaceID在HDFS上，会有多个Namenode，所以不同Namenode的namespaceID是不同的，分别管理一组blockpoolID。
• （2）clusterID集群id，全局唯一
• （3）cTime属性标记了namenode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。
• （4）storageType属性说明该存储目录包含的是namenode的数据结构。
• （5）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。
• （6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。

SecondaryNameNode目录结构

• Secondary NameNode用来监控HDFS状态的辅助后台程序，每隔一段时间获取HDFS元数据的快照。
• SecondaryNameNode的namesecondary/current目录和主namenode的current目录的布局相同。
• 好处：在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。
• 方法一：将SecondaryNameNode中数据拷贝到namenode存储数据的目录；
• 方法二：使用-importCheckpoint选项启动namenode守护进程，从而将SecondaryNameNode用作新的主namenode。

模拟namenode故障，并采用方法一，恢复namenode数据

• （1）kill -9 namenode进程

[hadoop@cmaster0 name]$ jps
2096 DataNode
2371 NodeManager
1992 NameNode
2705 Jps
[hadoop@cmaster0 name]$ kill -9 1992
[hadoop@cmaster0 name]$ jps
2096 DataNode
2371 NodeManager
2715 Jps

• （2）删除namenode存储的数据

[hadoop@cmaster0 name]$ rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*
[hadoop@cmaster0 name]$ pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs/name
[hadoop@cmaster0 name]$ ll
total 0

• （3）拷贝SecondaryNameNode中数据到原namenode存储数据目录

[hadoop@cslave1 namesecondary]$ hostname
cslave1
[hadoop@cslave1 namesecondary]$ scp -r /opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/* cmaster0:/opt/module/hadoop-2.7.2/data/tmp/dfs/name/

• （4）重新启动namenode

[hadoop@cmaster0 sbin]$ jps
2763 Jps
2096 DataNode
2371 NodeManager
[hadoop@cmaster0 sbin]$ hadoop-daemon.sh start namenode
starting namenode, logging to /opt/module/hadoop-2.7.2/logs/hadoop-hadoop-namenode-cmaster0.out
[hadoop@cmaster0 sbin]$ jps
2795 NameNode
2096 DataNode
2371 NodeManager
2847 Jps

模拟namenode故障，并采用方法二，恢复namenode数据

• 修改hdfs-site.xml中的

  dfs.namenode.checkpoint.period
  120



  dfs.namenode.name.dir
  /opt/module/hadoop-2.7.2/data/tmp/dfs/name

• （1）kill -9 namenode进程
• （2）删除namenode存储的数据
• rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*
• （3）如果SecondaryNameNode不和Namenode在一个主机节点上，需要将SecondaryNameNode存储数据的目录拷贝到Namenode存储数据的平级目录。
• （4）导入检查点数据
• bin/hdfs namenode -importCheckpoint
• （5）启动namenode
• sbin/hadoop-daemon.sh start namenode
• （6）如果提示文件锁了，可以删除in_use.lock
• rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/in_use.lock

集群安全模式操作

• Namenode启动时，首先将映像文件（fsimage）载入内存，并执行编辑日志（edits）中的各项操作。一旦在内存中成功建立文件系统元数据的映像，则创建一个新的fsimage文件和一个空的编辑日志。此时，namenode开始监听datanode请求。但是此刻，namenode运行在安全模式，即namenode的文件系统对于客户端来说是只读的。
• 系统中的数据块的位置并不是由namenode维护的，而是以块列表的形式存储在datanode中。在系统的正常操作期间，namenode会在内存中保留所有块位置的映射信息。在安全模式下，各个datanode会向namenode发送最新的块列表信息，namenode了解到足够多的块位置信息之后，即可高效运行文件系统。
• 如果满足“最小副本条件”，namenode会在30秒钟之后就退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别（默认值：dfs.replication.min=1）。在启动一个刚刚格式化的HDFS集群时，因为系统中还没有任何块，所以namenode不会进入安全模式。
• 集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式。
• （1）bin/hdfs dfsadmin -safemode get （功能描述：查看安全模式状态）
• （2）bin/hdfs dfsadmin -safemode enter （功能描述：进入安全模式状态）
• （3）bin/hdfs dfsadmin -safemode leave （功能描述：离开安全模式状态）
• （4）bin/hdfs dfsadmin -safemode wait （功能描述：等待安全模式状态）

模拟等待安全模式

• 1）先进入安全模式：bin/hdfs dfsadmin -safemode enter
• 2）执行下面的脚本

#!/bin/bash
bin/hdfs dfsadmin -safemode wait
bin/hdfs dfs -put ~/hello.txt /root/hello.txt

• 3）再打开一个窗口，执行：bin/hdfs dfsadmin -safemode leave

Namenode多目录配置

• dfs.namenode.name.dir 属性可以配置多个目录，如/data1/dfs/name,/data2/dfs/name,/data3/dfs/name,…。各个目录存储的文件结构和内容都完全一样，相当于备份，这样做的好处是当其中一个目录损坏了，也不会影响到Hadoop的元数据，特别是当其中一个目录是NFS（网络文件系统Network File System，NFS）之上，即使你这台机器损坏了，元数据也得到保存。

• dfs.datanode.data.dir 也属性可以配置多个目录，但含义同dfs.namenode.name.dir完全不一样，dfs.datanode.data.dir不是冗余备份的作用，而是将多个目录捆绑打包，用于存放数据。

• 1）namenode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性。

• 2）具体配置如下：hdfs-site.xml

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