六、HDFS中的NameNode和SecondaryNameNode

       上篇博客介绍了Hadoop的核心组件HDFS,本篇主要介绍HDFS中的NameNode和SecondaryNameNode,关注专栏《破茧成蝶——大数据篇》查看相关系列的文章~


目录

一、NameNode和SecondaryNameNode工作机制

1.1 NameNode启动

1.2 SecondaryNameNode工作

1.3 详细工作机制

二、Fsimage和Edits解析

2.1 概述

2.2 查看fsimage文件

2.3 查看edits文件

三、CheckPoint时间设置

四、NameNode故障处理

五、安全模式

5.1 安全模式基本操作语句


 

       在这之前,我们首先得弄明白一件事情:NameNode中的元数据是存储在哪里的?我们可以假设一下,如果元数据存储在NameNode节点的磁盘中,因为经常需要进行随机访问,还要响应客户请求,必然是效率过低。因此,元数据需要存放在内存中。但如果只存在内存中,一旦断电,元数据丢失,整个集群就无法工作了。因此,需要有一个备份元数据的“东西”,这个“东西”我们称之为——FsImage。
       这样又会带来新的问题,当在内存中的元数据更新时,如果同时更新FsImage,就会导致效率过低,但如果不更新,就会发生一致性问题,一旦NameNode节点断电,就会产生数据丢失。因此,引入Edits文件(只进行追加操作,效率很高)。每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到Edits中。这样,一旦NameNode节点断电,可以通过FsImage和Edits的合并,合成元数据。
       但是,如果长时间添加数据到Edits中,会导致该文件数据过大,效率降低,而且一旦断电,恢复元数据需要的时间过长。因此,需要定期进行FsImage和Edits的合并,如果这个操作由NameNode节点完成,又会导致效率过低的问题出现。因此,引入一个新的节点SecondaryNamenode,专门用于FsImage和Edits的合并。

一、NameNode和SecondaryNameNode工作机制

1.1 NameNode启动

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

1.2 SecondaryNameNode工作

       (1)SecondaryNameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。(2)SecondaryNameNode请求执行CheckPoint。(3)NameNode滚动正在写的Edits日志。(4)将滚动前的编辑日志和镜像文件拷贝到SecondaryNameNode。(5)Secondary NameNode加载编辑日志和镜像文件到内存,并合并。(6)生成新的镜像文件fsimage.chkpoint。(7)拷贝fsimage.chkpoint到NameNode。(8)NameNode将fsimage.chkpoint重新命名成fsimage。

       名词解释:

       Fsimage:NameNode内存中元数据序列化后形成的文件。
       Edits:记录客户端更新元数据信息的每一步操作(可通过Edits运算出元数据)。

1.3 详细工作机制

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

2.1 概述

       NameNode被格式化之后,会在如下目录下产生fsimage文件,如下图所示:

       (1)fsimage文件:HDFS文件系统元数据的一个永久检查点,其中包含HDFS文件系统的所有目录和文件inode的序列化信息。

       (2)edits文件:存放HDFS文件系统的所有更新操作的路径,文件系统客户端执行的所有写操作首先会被记录到edits文件中。

       (3)seen_txid文件:保存的是一个数字,就是edits_的数字。

       (4)VERSION文件:存放相关的ID信息。

       (5)每次NameNode启动都会将fsimage文件读到内存中,加载edits里面的更新操作,保证内存中的元数据信息是最新的、同步的,可以看成NameNode启动的时候就将fsimage和edits文件进行了合并。

2.2 查看fsimage文件

       (1)查看相关命令

[root@master current]# hdfs
oiv                  apply the offline fsimage viewer to an fsimage
oev                  apply the offline edits viewer to an edits file

       (2)基本语法

hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径

       (3)查看fsimage

[root@master current]# pwd
/opt/modules/hadoop-2.7.2/data/tmp/dfs/name/current
[root@master current]# hdfs oiv -p XML -i fsimage_0000000000000000031 -o /opt/modules/hadoop-2.7.2/fsimage.xml
[root@master current]# cat /opt/modules/hadoop-2.7.2/fsimage.xml

       结果为:

2.3 查看edits文件

       (1)基本语法

hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径

       (2)查看edits

[root@master current]# pwd
/opt/modules/hadoop-2.7.2/data/tmp/dfs/name/current
[root@master current]# hdfs oev -p XML -i edits_0000000000000000068-0000000000000000069 -o /opt/modules/hadoop-2.7.2/edits.xml
[root@master current]# cat /opt/modules/hadoop-2.7.2/edits.xml

       结果为:

三、CheckPoint时间设置

       通常情况下,SecondaryNameNode每隔一小时执行一次,可以在hdfs-default.xml中设置参数的大小:

       一分钟检查一次操作数,当操作数达到100万时,SecondaryNameNode执行一次:

四、NameNode故障处理

       当NameNode发生故障时,可以采用如下方法恢复数据。

方法一:将SecondaryNameNode中数据拷贝到NameNode存储数据的目录

       1、杀死NameNode进程

kill -9 进程号

       2、删除NameNode存储的数据(在本项目中路径为:/opt/modules/hadoop-2.7.2/data/tmp/dfs/name)

       3、拷贝SecondaryNameNode中数据到原NameNode存储数据的目录,SecondaryNameNode安装在slave02上,使用scp分发命令将其拷贝到master节点的NameNode上。

scp -r ./* master:/opt/modules/hadoop-2.7.2/data/tmp/dfs/name/

       4、启动NameNode

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/modules/hadoop-2.7.2/data/tmp/dfs/name</value>
</property>

       2、杀死NameNode进程(同上)

       3、删除NameNode存储的数据(同上)

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

       5、导入检查点数据

[root@master ~]# hdfs namenode -importCheckpoint

       6、启动NameNode(同上)

五、安全模式

       NameNode启动时,首先加载fsimage文件到内存,并执行edits中的各项操作。一旦在内存中成功建立文件系统元数据的映像,则创建一个新的fsimage文件和一个空的edits文件。此时NameNode开始监听DataNode请求。在此期间,NameNode一直运行在安全模式下,即NameNode文件系统对于客户端来说是只读的。

       系统中数据块的位置并不是由NameNode维护的,而是以块的形式存储在DataNode中。在系统正常操作期间,NameNode会在内存中保留所有块列表信息,NameNode了解到足够多的块位置信息后即可高效运行文件系统。

       如果满足“最小副本条件”,NameNode会在30秒之后退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别(默认值:dfs.replication.min=1)。在启动一个刚刚格式化的HDFS集群时,因为系统中还没有任何块,所以不会进入安全模式。

5.1 安全模式基本操作语句

查看安全模式状态:bin/hdfs dfsadmin -safemode get
进入安全模式:bin/hdfs dfsadmin -safemode enter
离开安全模式:bin/hdfs dfsadmin -safemode leave
等待安全模式:bin/hdfs dfsadmin -safemode wait

        本文到此也就结束了,在次过程中你们遇到什么问题,欢迎留言,让我看看你们都遇到了哪些问题~

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

象在舞

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值