当前位置: 代码迷 >> 综合 >> Hadoop(五)—— HDFS之NameNode、SecondaryNameNode
  详细解决方案

Hadoop(五)—— HDFS之NameNode、SecondaryNameNode

热度:73   发布时间:2024-01-27 05:08:49.0

文章目录

  • 1. NamaNode和Secondary NameNode工作机制
  • 2. 镜像文件和编辑日志文件
  • 3. 滚动编辑日志
  • 4. NameNode版本号
  • 5. Secondary NameNode目录结构
    • 5.1 目录结构
    • 5.2 还原元数据的方法
  • 6. 集群安全模式操作
  • 7. NameNode多目录配置

1. NamaNode和Secondary NameNode工作机制

在这里插入图片描述

第一阶段:NameNode启动

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

第二阶段:Secondary NameNode工作

  1. Secondary NameNode询问NameNode是否需要checkpoint(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

注:每个block的元数据占150byte。

checkpoint检查时间参数设置

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

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

2. 镜像文件和编辑日志文件

NameNode被格式化之后,将在/opt/module/hadoop-2.8.4/data/dfs/name/current目录中产生如下文件,注只能在NameNode所在的节点才能找到此文件。

edits_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION

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

oiv查看fsimage文件

# hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
hdfs oiv -p XML -i fsimage_0000000000000000316 -o /opt/fsimage.xml
cat /opt/module/hadop-2.8.4/fsimage.xml

oev查看edits文件

# hdfs oev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径
hdfs oev -p XML -i edits_0000000000000000135-0000000000000000135 -o /opt/module/hadoop-2.8.4/edits.xml
cat /opt/module/hadoop-2.8.4/edits.xml

每个RECORD记录了一次操作,比如图中的
OP_ADD代表添加文件操作、OP_MKDIR代表创建目录操作。里面还记录了
文件路径(PATH)
修改时间(MTIME)
添加时间(ATIME)
客户端名称(CLIENT_NAME)
客户端地址(CLIENT_MACHINE)
权限(PERMISSION_STATUS)等非常有用的信息

3. 滚动编辑日志

正常情况HDFS文件系统有更新操作时,就会滚动编辑日志。也可以用命令强制滚动编辑日志(前提必须启动集群)。
举例:
原文件名edits_inprogress_0000000000000000321,执行以下命令后,edits_inprogress_0000000000000000321 => edits_inprogress_0000000000000000323

hdfs dfsadmin -rollEdits
Successfully rolled edit logs.
New segment starts at txid 323

4. NameNode版本号

在/opt/module/hadoop-2.8.4/data/dfs/name/current这个目录下查看VERSION

namespaceID=1778616660
clusterID=CID-bc165781-d10a-46b2-9b6f-3beb1d988fe0
cTime=1552918200296
storageType=NAME_NODE
blockpoolID=BP-274621862-192.168.1.111-1552918200296
layoutVersion=-63
  • namespaceID在HDFS上,会有多个NameNode,所以不同NameNode的namespaceID是不同的,分别管理一组blockpoolID。
  • clusterID集群id,全局唯一
  • cTime属性标记了NameNode存储系统的创建时间,对于刚刚格式化的存储系统,这个属性为0;但是在文件系统升级之后,该值会更新到新的时间戳。
  • storageType属性说明该存储目录包含的是NameNode的数据结构。
  • blockpoolID:一个block pool id标识一个block pool,并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中,在后续的启动过程中,会再次load并使用。
  • layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。
  • storageID (存储ID):是DataNode的ID,不唯一

5. Secondary NameNode目录结构

5.1 目录结构

在/opt/module/hadoop-2.8.4/data/dfs/namesecondary/current这个目录中查看SecondaryNameNode目录结构。

edits_0000000000000000001-0000000000000000002
fsimage_0000000000000000002
fsimage_0000000000000000002.md5
VERSION

好处:在主NameNode发生故障时(假设没有及时备份数据),可以从SecondaryNameNode恢复数据。

5.2 还原元数据的方法

方式一:将SecondaryNameNode中的数据复制到name下

# 1.jps查看NameNode进程号,杀掉NameNode,模拟NameNode挂掉 
kill -9 pid# 2.删除name目录下的所有文件
cd /usr/local/hadoop-3.2.0/data/dfs/name
rm -rf *# 3.复制数据
cd /usr/local/hadoop-3.2.0/data/dfs
cp -r namesecondary/* name# 4.单独启动NameNode
hadoop-daemon.sh start namenode

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

# 1. 修改hdfs-site.xml
vim hdfs-site.xml
<property><name>dfs.namenode.checkpoint.period</name><value>120</value>  <!-- 2分钟 -->
</property>
<property><name>dfs.namenode.name.dir</name><value>/usr/local/hadoop-3.2.0/data/dfs/name</value>
</property># 2.模拟NameNode挂掉,并删除NameNode数据
kill -9 pid
cd /usr/local/hadoop-3.2.0/data/dfs/name
rm -rf *# 3.如果nn和sn不在同一个节点,需要先将sn复制到和nn同级的目录,然后再导入检查点数据。(等待一会ctrl+c结束)
hdfs namenode -importCheckpoint
# 如果报错the directory is already locked。删除ss下的lock文件即可。# 4.单独启动NameNode
hadoop-daemon.sh start namenode

6. 集群安全模式操作

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

7. NameNode多目录配置

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

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>
  相关解决方案