HDFS中NameNode工作机制
引言
NameNode:
- 存储元数据
- 管理整个HDFS集群
DataNode:
存储数据的block
SecondaryNameNode:
辅助HDFS完成一些事情
NameNode和SecondaryNameNode工作流程
编辑日志文件:edits
记载客户端对HDFS的增删改查的操作日志
镜像文件:fsimage
记载元数据(HDFS上存储的文件目录)及操作日志
NameNode和SecondaryNameNode工作机制
工作流程详解
-
第一阶段:namenode启动
-
第一次启动namenode格式化后,创建fsimage和edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
-
客户端对元数据进行增删改的请求。
-
namenode记录操作日志,更新滚动日志。
-
namenode在内存中对数据进行增删改查。
-
-
第二阶段:Secondary NameNode工作
-
Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。
-
Secondary NameNode请求执行checkpoint。
-
namenode滚动正在写的edits日志。
-
将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
-
Secondary NameNode加载编辑日志和镜像文件到内存,并合并。
-
生成新的镜像文件fsimage.chkpoint。
-
拷贝fsimage.chkpoint到namenode。
-
namenode将fsimage.chkpoint重新命名成fsimage。
-
chkpoint检查的两种触发条件
- 通常情况下,SecondaryNameNode每隔一小时执行一次检查点操作。
[hdfs-default.xml]
<!--两次检查点创建之间的固定时间间隔,默认3600,即1小时。所以去ann snn 看到的fsimage 相隔1个小时。--> <property> <name>dfs.namenode.checkpoint.period</name> <value>3600</value> </property>
- 一分钟检查namenode的事务数量。若检查事务数达到这个值1,000,000,也触发一次SecondaryNameNode的checkpoint操作。
<!--hdfs-site.xml文件设置--> <!--事务数量配置--> <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上保存的fsimage的数目,超出的会被删除。默认保存2个。--> <property> <name>dfs.namenode.num.checkpoints.retained</name> <value>2</value> </property>
镜像文件和编辑日志文件
namenode被格式化之后,将在/opt/app/hadoop/data/tmp/dfs/name/current目录中产生如下文件:
由于我的NameNode没有格式化,只格式化了hadoop,并且将temp文件夹作为存储日志文件的文件夹,所以以下文件的访问目录均为:/opt/app/hadoop/temp/dfs/name/current
edits_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION
- Fsimage文件:HDFS文件系统元数据的一个永久性的检查点,其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。
- Edits文件:存放HDFS文件系统的所有更新操作的路径,文件系统客户端执行的所有写操作首先会被记录到edits文件中。
- seentxid文件:保存的是一个数字,就是最后一个edits的数字
-
每次Namenode启动的时候都会将fsimage文件读入内存,并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作,保证内存中的元数据信息是最新的、同步的,可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。
Notes:这些文件被意外删除后将无法恢复,需谨慎!
NameNode版本号
如上图:在/opt/app/hadoop/data/tmp/dfs/name/current这个目录下查看VERSION
namenode版本号具体解释:
-
namespaceID:在HDFS上,会有多个Namenode,所以不同Namenode的namespaceID是不同的(主从架构:一个NameNode多个DataNode),分别管理一组blockpoolID。
-
clusterID:集群id,全局唯一
-
cTime:属性标记了NameNode存储系统的创建时间,对于刚刚格式化的存储系统,这个属性为0;但是在文件系统升级之后,该值会更新到新的时间戳。
-
storageType:属性说明该存储目录包含的是NameNode的数据结构。
-
blockpoolID:一个block pool id标识一个block pool,并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中,在后续的启动过程中,会再次load并使用。其针对每一个Namespace所对应blockpool的ID,该ID包括了其对应的NameNode节点的ip地址。
-
layoutVersion:是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。
SecondaryNameNode详解
SecondaryNameNode目录结构
SecondaryNameNode用来监控HDFS状态的辅助后台程序,每隔一段时间获取HDFS元数据的快照。
查看路径:/opt/app/hadoop/data/tmp/dfs/namesecondary/current
SecondaryNameNode的namesecondary/current目录和主NameNode的current目录的布局相同。好处:在主namenode发生故障时(假设没有及时备份数据),可以从SecondaryNameNode恢复数据。
NameNode恢复数据的方法
首先模拟NameNode损坏,即杀死NameNode进程:
kill -9 进程ID:强制将某进程杀死
方法一:将SecondaryNameNode中数据拷贝到namenode存储数据的目录;
方法二:使用-importCheckpoint选项启动namenode守护进程,从而将SecondaryNameNode中数据拷贝到namenode目录中。
-
案例实操(一):模拟namenode故障,并采用方法一,恢复namenode数据
-
kill -9 namenode进程/opt/app/hadoop/data/tmp/dfs/name)
rm -rf /opt/app/hadoop/data/tmp/dfs/name/*
拷贝SecondaryNameNode中数据到原namenode存储数据目录
cp -R /opt/app/hadoop/data/tmp/dfs/namesecondary/* /opt/app/hadoop/data/tmp/dfs/name/
重新启动namenode:
sbin/hadoop-daemon.sh start namenode
-
-
案例实操(二):模拟namenode故障,并采用方法二,恢复namenode数据
-
修改hdfs-site.xml中的
<property> <name>dfs.namenode.checkpoint.period</name> <value>120</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/home/bigdata/hadoop-2.8.5/data/tmp/dfs/name</value> </property>
-
-
-
kill -9 namenode进程
-
删除namenode存储的数据(/opt/app/hadoop/data/tmp/dfs/name)
rm -rf /opt/app/hadoop//data/tmp/dfs/name/*
-
如果SecondaryNameNode不和Namenode在一个主机节点上,需要将SecondaryNameNode存储数据的目录拷贝到Namenode存储数据的平级目录
[uek@node2 dfs]$ pwd
/opt/app/hadoop/data/tmp/dfs
[uek@node2 dfs]$ ls
data name namesecondary
-
导入检查点数据(等待一会ctrl+c结束掉)
bin/hdfs namenode -importCheckpoint
-
启动namenode
sbin/hadoop-daemon.sh start namenode
-
如果提示文件锁了,可以删除in_use.lock
rm -rf /opt/app/hadoop/data/tmp/dfs/namesecondary/in_use.lock
-
Namenode多目录配置实现单机节点数据安全性问题
- namenode的本地目录可以配置成多个,且每个目录存放内容相同,增加了可靠性。
- 具体配置如下:
hdfs-site.xml <property> <name>dfs.namenode.name.dir</name> <value>opt/app/hadoop/data/dfs/name1,opt/app/hadoop/data/dfs/name2</value> </property>
集群安全模式操作
概述
Namenode启动时,首先将映像文件(fsimage)载入内存,并执行编辑日志(edits)中的各项操作。一旦在内存中成功建立文件系统元数据的映像,则创建一个新的fsimage文件和一个空的编辑日志。此时,namenode开始监听datanode请求。但是此刻,namenode运行在安全模式,即namenode的文件系统对于客户端来说是只读的。
系统中的数据块的位置并不是由namenode维护的,而是以块列表的形式存储在datanode中。在系统的正常操作期间,namenode会在内存中保留所有块位置的映射信息。在安全模式下,各个datanode会向namenode发送最新的块列表信息,namenode了解到足够多的块位置信息之后,即可高效运行文件系统。
如果满足“最小副本条件”,namenode会在30秒钟之后就退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别(默认值:dfs.replication.min=1)。
在启动一个刚刚格式化的HDFS集群时,因为系统中还没有任何块,所以namenode不会进入安全模式。
基本语法
- 集群处于安全模式,不能执行重要操作(写操作)。集群启动完成后,自动退出安全模式。
- bin/hdfs dfsadmin -safemode get (功能描述:查看安全模式状态)
- bin/hdfs dfsadmin -safemode enter (功能描述:进入安全模式状态)
- bin/hdfs dfsadmin -safemode leave (功能描述:离开安全模式状态)
- bin/hdfs dfsadmin -safemode wait (功能描述:等待安全模式状态)
案例
- 模拟等待安全模式
- 先进入安全模式:bin/hdfs dfsadmin -safemode enter
- 执行下面的脚本
编辑一个脚本 #!/bin/bash bin/hdfs dfsadmin -safemode wait bin/hdfs dfs -put ~/hello.txt /root/hello.txt
- 再打开一个窗口,执行:bin/hdfs dfsadmin -safemode leave