深入浅出之namenode工作原理剖析

谁借莪１个温暖的怀抱￠ 2022-06-05 01:30 260阅读 0赞

*问题场景：*

*1* *、集群启动后，可以查看文件，但是上传文件时报错，打开* *web* *页面可看到* *namenode* *正处于* *safemode* *状态，怎么处理？*

*2* *、* *Namenode* *服务器的磁盘故障导致* *namenode* *宕机，如何挽救集群及数据？*

*3* *、* *Namenode* *是否可以有多个？* *namenode* *内存要配置多大？* *namenode* *跟集群数据存储能力有关系吗？*

*4* *、文件的* *blocksize* *究竟调大好还是调小好？*

*……*

**1.NAMENODE** **职责**

**NAMENODE职责：**

**       负责客户端请求的响应**

**       元数据的管理（查询，修改）**

**2** **元数据管理**

**namenode对数据的管理采用了三种存储形式：**

**内存元数据(NameSystem)**

**磁盘元数据镜像文件**

**数据操作日志文件（可通过日志运算出元数据）**

### 3.元数据存储机制 ###

A、内存中有一份完整的元数据(内存meta data)

B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)

C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）注： **当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中**

**4.namenode工作机制**

**   ![Center][]** ![Image 1][]

1 ） 第一阶段： namenode 启动

（ 1 ）第一次启动 namenode 格式化后，创建 fsimage 和 edits （在 namenode 所在结点的 hadooop/data 目录下）文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。

（ 2 ）客户端对元数据进行增删改的请求

（ 3 ） namenode 记录操作日志，更新滚动日志。

（ 4 ） namenode 在内存中对数据进行增删改查

2 ）第二阶段： 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

**补充：**

**1.checkpoint的附带作用**

**           namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据**

chkpoint检查时间参数设置

（1）通常情况下，SecondaryNameNode每隔一小时执行一次。

\[hdfs-default.xml\]

<name>dfs.namenode.checkpoint.period</name>

</property>

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

<name>dfs.namenode.checkpoint.txns</name>

<description>操作动作次数</description>

</property>

<name>dfs.namenode.checkpoint.check.period</name>

<description> 1分钟检查一次操作次数</description>

</property>

2.namenode目录

默认namenode目录，fsemage等存储在data/tmp下。不安全，可以自定义设置

元数据目录说明

在第一次部署好Hadoop集群的时候，我们需要在NameNode（NN）节点上格式化磁盘：

$HADOOP\_HOME/bin/hdfs namenode -format

格式化完成之后，将会在$dfs.namenode.name.dir/current目录下如下的文件结构

current/

|-- VERSION

|-- edits\_\*

|-- fsimage\_0000000000008547077

|-- fsimage\_0000000000008547077.md5

\`-- seen\_txid

其中的dfs.name.dir是在hdfs-site.xml文件中配置的，默认值如下：

<value>file://$\{hadoop.tmp.dir\}/dfs/name</value>

</property>

hadoop.tmp.dir是在core-site.xml中配置的，默认值如下

<name>hadoop.tmp.dir</name>

<value>/tmp/hadoop-$\{user.name\}</value>

<description>A base for other temporary directories.</description>

</property>

修改namdenode文件目录

**  <value>/home/hadoop/name1,/home/hadoop/name2</value** >

</property>

注：重新启动hdfs以后，namenode的元数据，会同时往两块nam1和name2磁盘或文件夹里书写，两个文件数据一样，相当于备份。 同理datanode也可以配置多块磁盘或者文件，相当于扩容。可以同时往多个datanode磁盘书写数据，减少磁盘io压力。

dfs.namenode.name.dir属性可以配置多个目录，

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

下面对$dfs.namenode.name.dir/current/目录下的文件进行解释。

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

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

fsimage\_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文件进行了合并。

**2）** **oiv查看fsimage文件**

**（1）查看oiv和oev命令**

\[robot@hadoop102 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）案例实操

\[robotu@hadoop102 current\]$ pwd

/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current

\[robot@hadoop102 current\]$ hdfs oiv -p XML -i fsimage\_0000000000000000025 -o /opt/module/hadoop-2.7.2/fsimage.xml

\[robot@hadoop102 current\]$ cat /opt/module/hadoop-2.7.2/fsimage.xml

将显示的xml文件内容拷贝到eclipse中创建的xml文件中，并格式化。

3）oev查看edits文件

（1）基本语法

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

（2）案例实操

\[robot@hadoop102 current\]$ hdfs oev -p XML -i edits\_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-2.7.2/edits.xml

\[robot@hadoop102 current\]$ cat /opt/module/hadoop-2.7.2/edits.xml

将显示的xml文件内容拷贝到eclipse中创建的xml文件中，并格式化。

**4.下面对$dfs.namenode.name.dir/current/目录下的文件进行解释。**

namespaceID=934548976

clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196

cTime=0

storageType=NAME\_NODE

blockpoolID=BP-893790215-192.168.24.72-1383809616115

layoutVersion=-47

（1）、namespaceID是文件系统的唯一标识符，在文件系统首次格式化之后生成的；

（2）、storageType说明这个文件存储的是什么进程的数据结构信息（如果是DataNode，storageType=DATA\_NODE）；

（3）、cTime表示NameNode存储时间的创建时间，由于我的NameNode没有更新过，所以这里的记录值为0，以后对NameNode升级之后，cTime将会记录更新时间戳；

（4）、layoutVersion表示HDFS永久性数据结构的版本信息， 只要数据结构变更，版本号也要递减，此时的HDFS也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的NameNode无法使用；

（5）、clusterID是系统生成或手动指定的集群ID，在-clusterid选项中可以使用它；如下说明

\- 使用如下命令格式化一个Namenode：

$HADOOP\_HOME/bin/hdfs namenode -format \[-clusterId <cluster\_id>\]

选择一个唯一的cluster\_id，并且这个cluster\_id不能与环境中其他集群有冲突。如果没有提供cluster\_id，则会自动生成一个唯一的ClusterID。

b、使用如下命令格式化其他Namenode：

$HADOOP\_HOME/bin/hdfs namenode -format -clusterId <cluster\_id>

c、升级集群至最新版本。在升级过程中需要提供一个ClusterID，例如：

$HADOOP\_PREFIX\_HOME/bin/hdfs start namenode --config $HADOOP\_CONF\_DIR  -upgrade -clusterId <cluster\_ID>

如果没有提供ClusterID，则会自动生成一个ClusterID。

（6）、blockpoolID：是针对每一个Namespace所对应的blockpool的ID，上面的这个BP-893790215-192.168.24.72-1383809616115就是在我的ns1的namespace下的存储块池的ID，这个ID包括了其对应的NameNode节点的ip地址。

2、$dfs.namenode.name.dir/current/seen\_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits\_\*文件的尾数，namenode重启的时候，会按照seen\_txid的数字，循序从头跑edits\_0000001~到seen\_txid的数字。所以当你的hdfs发生异常重启的时候，一定要比对seen\_txid内的数字是不是你edits最后的尾数，不然会发生建置namenode时metaData的资料有缺少，导致误删Datanode上多余Block的资讯。

3、$dfs.namenode.name.dir/current目录下在format的同时也会生成fsimage和edits文件，及其对应的md5校验文件

补充：seen\_txid

文件中记录的是edits滚动的序号，每次重启namenode时，namenode就知道要将哪些edits进行加载edits

[Center]: https://img-blog.csdn.net/20171114122514628?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMjY0NDI1NTM=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
[Image 1]: