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

转自 https://blog.csdn.net/qq_26442553/article/details/78529256

问题场景：

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工作机制

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

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

3.元数据存储机制

猜你喜欢