重启namenode速度慢，耗时很久加载fsimage问题解决办法

最新推荐文章于 2024-07-20 17:52:45 发布

首席撩妹指导官

最新推荐文章于 2024-07-20 17:52:45 发布

阅读量871

点赞数

文章标签： hadoop hdfs 大数据

本文链接：https://blog.csdn.net/qq_36864672/article/details/130494308

版权

文章介绍了在HDFS中，如果Namenode重启速度慢，可以通过执行特定命令来合并元数据，加快重启速度。fsimage和editslog是HDFS中存储元数据的关键文件，fsimage不包含DataNode信息，而editslog记录了事务操作。oiv和oev命令用于分析和查看这两个文件的内容，帮助理解HDFS的数据结构和操作历史。在Namenode启动时，它会加载fsimage并应用editslog，以恢复最新的文件系统状态。

摘要由CSDN通过智能技术生成

如果重启namenode速度慢，耗时很久加载fsimage问题解决办法
可以需要定期执行以下命令提前合并元数据。

hdfs dfsadmin -safemode enter 
hdfs dfsadmin -saveNamespace
hdfs dfsadmin -safemode leave

（在关闭hdfs服务前，执行一上命令，会极大的加快重启namenode速度）

Fsimage和Edits log文件分析

查看oiv和oev命令

[root@node1 ~]# hdfs|grep o.v
oev apply the offline edits viewer to an edits file
oiv apply the offline fsimage viewer to an fsimage
复制
oiv查看Fsimage文件
（1）查看oiv命令

[root@node1 ~]# hdfs oiv --help
Usage: bin/hdfs oiv [OPTIONS] -i INPUTFILE -o OUTPUTFILE
Offline Image Viewer
View a Hadoop fsimage INPUTFILE using the specified PROCESSOR,
saving the results in OUTPUTFILE.
-i,--inputFile <arg> FSImage or XML file to process.
Optional command line arguments:
-o,--outputFile <arg> Name of output file. If the specified
file exists, it will be overwritten.
(output to stdout by default)
If the input file was an XML file, we
will also create an <outputFile>.md5 file.
-p,--processor <arg> Select which type of processor to apply
against image file. (XML|FileDistribution|
ReverseXML|Web|Delimited)
The default is Web.
（2）基本语法

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

（3）案例实操

[root@node1 current]# pwd
/var/itbaizhan/hadoop/full/dfs/name/current
[root@node1 current]# ll|grep fsimage
-rw-r--r-- 1 root root 722 10月 9 13:49 fsimage_0000000000000000047
-rw-r--r-- 1 root root 62 10月 9 13:49 fsimage_0000000000000000047.md5
-rw-r--r-- 1 root root 722 10月 9 14:49 fsimage_0000000000000000049
-rw-r--r-- 1 root root 62 10月 9 14:49 fsimage_0000000000000000049.md5
[root@node1 current]# hdfs oiv -p XML -i fsimage_0000000000000000049 -o /opt/hadoop-3.1.3/fsimage49.xml
2021-10-09 15:20:24,428 INFO offlineImageViewer.FSImageHandler: Loading 3 strings
[root@node1 current]# vim /opt/hadoop-3.1.3/fsimage49.xml
#格式化该xml文件:Ctrl+v-> !xmllint -format - -> 删除生成的<xml ..> ->保存并退出
[root@node1 current]# cat /opt/hadoop-3.1.3/fsimage49.xml
部分显示结果如下:

<?xml version="1.0"?>
<fsimage>
 <INodeSection>
  <lastInodeId>16392</lastInodeId>
  <numInodes>5</numInodes>
  <inode>
   <id>16385</id>
   <type>DIRECTORY</type>
   <name/>
   <mtime>1633749749273</mtime>
   <permission>root:supergroup:0755</permission>
   <nsquota>9223372036854775807</nsquota>
   <dsquota>-1</dsquota>
  </inode>
  <inode>
   <id>16386</id>
   <type>DIRECTORY</type>
   <name>user</name>
   <mtime>1633748876034</mtime>
   <permission>root:supergroup:0755</permission>
   <nsquota>-1</nsquota>
   <dsquota>-1</dsquota>
  </inode>
  <inode>
   <id>16387</id>
   <type>DIRECTORY</type>
   <name>root</name>
   <mtime>1633749176246</mtime>
   <permission>root:supergroup:0755</permission>
   <nsquota>-1</nsquota>
   <dsquota>-1</dsquota>
  </inode>
  <inode>
   <id>16388</id>
   <type>FILE</type>
   <name>hadoop-3.1.3.tar.gz</name>
   <replication>2</replication>
   <mtime>1633749066652</mtime>
   <atime>1633749010986</atime>
   <preferredBlockSize>134217728</preferredBlockSize>
   <permission>root:supergroup:0644</permission>
   <blocks>
    <block>
     <id>1073741825</id>
     <genstamp>1001</genstamp>
     <numBytes>134217728</numBytes>
    </block>
    <block>
     <id>1073741826</id>
     <genstamp>1002</genstamp>
     <numBytes>134217728</numBytes>
    </block>
    <block>
     <id>1073741827</id>
     <genstamp>1003</genstamp>
     <numBytes>69640404</numBytes>
    </block>
   </blocks>
   <storagePolicyId>0</storagePolicyId>
  </inode>
  <inode>
   <id>16389</id>
   <type>FILE</type>
   <name>test.txt</name>
   <replication>2</replication>
   <mtime>1633749176236</mtime>
   <atime>1633749175593</atime>
   <preferredBlockSize>134217728</preferredBlockSize>
   <permission>root:supergroup:0644</permission>
   <blocks>
    <block>
     <id>1073741828</id>
     <genstamp>1004</genstamp>
     <numBytes>38</numBytes>
    </block>
   </blocks>
   <storagePolicyId>0</storagePolicyId>
  </inode>
 </INodeSection>
  ......
</fsimage>

思考：观察发现Fsimage中没有记录块所对应DataNode，为什么？

在集群启动后，要求DataNode上报数据块信息，并间隔一段时间后再次上报。

oev查看Edits log文件

（1）查看oiv命令

[root@node1 current]# hdfs oev --help
Usage: bin/hdfs oev [OPTIONS] -i INPUT_FILE -o OUTPUT_FILE
Offline edits viewer
Parse a Hadoop edits log file INPUT_FILE and save results
in OUTPUT_FILE.
Required command line arguments:
-i,--inputFile <arg> edits file to process, xml (case
insensitive) extension means XML format,
any other filename means binary format.
XML/Binary format input file is not allowed
to be processed by the same type processor.
-o,--outputFile <arg> Name of output file. If the specified
file exists, it will be overwritten,
format of the file is determined
by -p option

Optional command line arguments:
-p,--processor <arg> Select which type of processor to apply
against image file, currently supported
processors are: binary (native binary format
that Hadoop uses), xml (default, XML
format), stats (prints statistics about
edits file)
（2）基本语法

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

（3）案例实操

[root@node1 current]# ll|grep edits
-rw-r--r-- 1 root root 515 10月 9 11:10 edits_0000000000000000001-0000000000000000008
-rw-r--r-- 1 root root 1048576 10月 9 11:22 edits_0000000000000000009-0000000000000000038
-rw-r--r-- 1 root root 42 10月 9 11:42 edits_0000000000000000039-0000000000000000040
-rw-r--r-- 1 root root 1048576 10月 9 11:42 edits_0000000000000000041-0000000000000000041
-rw-r--r-- 1 root root 42 10月 9 11:49 edits_0000000000000000042-0000000000000000043
-rw-r--r-- 1 root root 42 10月 9 12:49 edits_0000000000000000044-0000000000000000045
-rw-r--r-- 1 root root 42 10月 9 13:49 edits_0000000000000000046-0000000000000000047
-rw-r--r-- 1 root root 42 10月 9 14:49 edits_0000000000000000048-0000000000000000049
-rw-r--r-- 1 root root 1048576 10月 9 14:49 edits_inprogress_0000000000000000050
[root@node1 current]# hdfs oev -p XML -i edits_0000000000000000001-0000000000000000008 -o /opt/hadoop-3.1.3/editslog18.xml
[root@node1 current]# cat /opt/hadoop-3.1.3/editslog18.xml
显示结果如下:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<EDITS>
 <EDITS_VERSION>-64</EDITS_VERSION>
 <RECORD>
  <OPCODE>OP_START_LOG_SEGMENT</OPCODE>
  <DATA>
   <TXID>1</TXID>
  </DATA>
 </RECORD>
 <RECORD>
  <OPCODE>OP_MKDIR</OPCODE>
  <DATA>
   <TXID>2</TXID>
   <LENGTH>0</LENGTH>
   <INODEID>16386</INODEID>
   <PATH>/user</PATH>
   <TIMESTAMP>1633748876031</TIMESTAMP>
   <PERMISSION_STATUS>
    <USERNAME>root</USERNAME>
    <GROUPNAME>supergroup</GROUPNAME>
    <MODE>493</MODE>
   </PERMISSION_STATUS>
  </DATA>
 </RECORD>
 <RECORD>
  <OPCODE>OP_MKDIR</OPCODE>
  <DATA>
   <TXID>3</TXID>
   <LENGTH>0</LENGTH>
   <INODEID>16387</INODEID>
   <PATH>/user/root</PATH>
   <TIMESTAMP>1633748876034</TIMESTAMP>
   <PERMISSION_STATUS>
    <USERNAME>root</USERNAME>
    <GROUPNAME>supergroup</GROUPNAME>
    <MODE>493</MODE>
   </PERMISSION_STATUS>
  </DATA>
 </RECORD>
 <RECORD>
  <OPCODE>OP_ADD</OPCODE>
  <DATA>
   <TXID>4</TXID>
   <LENGTH>0</LENGTH>
   <INODEID>16388</INODEID>
   <PATH>/user/root/hadoop-3.1.3.tar.gz._COPYING_</PATH>
   <REPLICATION>2</REPLICATION>
   <MTIME>1633749010986</MTIME>
   <ATIME>1633749010986</ATIME>
   <BLOCKSIZE>134217728</BLOCKSIZE>
   <CLIENT_NAME>DFSClient_NONMAPREDUCE_1752542758_1</CLIENT_NAME>
   <CLIENT_MACHINE>192.168.20.101</CLIENT_MACHINE>
   <OVERWRITE>true</OVERWRITE>
   <PERMISSION_STATUS>
    <USERNAME>root</USERNAME>
    <GROUPNAME>supergroup</GROUPNAME>
    <MODE>420</MODE>
   </PERMISSION_STATUS>
   <ERASURE_CODING_POLICY_ID>0</ERASURE_CODING_POLICY_ID>
   <RPC_CLIENTID>d021df05-6937-4fc7-9474-ffcbf27f0f14</RPC_CLIENTID>
   <RPC_CALLID>3</RPC_CALLID>
  </DATA>
 </RECORD>
 <RECORD>
  <OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
  <DATA>
   <TXID>5</TXID>
   <BLOCK_ID>1073741825</BLOCK_ID>
  </DATA>
 </RECORD>
 <RECORD>
  <OPCODE>OP_SET_GENSTAMP_V2</OPCODE>
  <DATA>
   <TXID>6</TXID>
   <GENSTAMPV2>1001</GENSTAMPV2>
  </DATA>
 </RECORD>
 <RECORD>
  <OPCODE>OP_ADD_BLOCK</OPCODE>
  <DATA>
   <TXID>7</TXID>
   <PATH>/user/root/hadoop-3.1.3.tar.gz._COPYING_</PATH>
   <BLOCK>
    <BLOCK_ID>1073741825</BLOCK_ID>
    <NUM_BYTES>0</NUM_BYTES>
    <GENSTAMP>1001</GENSTAMP>
   </BLOCK>
   <RPC_CLIENTID/>
   <RPC_CALLID>-2</RPC_CALLID>
  </DATA>
 </RECORD>
 <RECORD>
  <OPCODE>OP_END_LOG_SEGMENT</OPCODE>
  <DATA>
   <TXID>8</TXID>
  </DATA>
 </RECORD>
</EDITS>

当文件系统客户端进行了写操作（例如创建或移动了文件），这个事务首先在edits log中记录下来。NameNode在内存中有文件系统的元数据，当edits log记录结束后，就更新内存中的元数据。内存中的元数据用于响应客户端的读请求。

edits log在磁盘上表现为一定数量的文件。每个文件称为片段（Segment），前缀“edits”，后缀是其中包含的事务ID（transaction IDs）。每个写操作事务都仅仅打开一个文件（比如：edits_inprogress_00000000000010），写完后冲刷缓冲区并同步到磁盘，然后返回客户端success状态码。如果NameNode的元数据需要写到多个目录中，则对于每个写事务需要所有的写操作都完成，并冲刷缓冲区同步到磁盘才返回success状态码。这样就可以保证在发生宕机的时候没有事务数据丢失。

用户的操作是一个事务，每个操作NN都要先将操作记录到edits log中，如果给NN指定了多个目录，则在多个目录中都存在edits log文件，用户的操作要在多个目录中都写完成，才让NN同步数据到内存中。当NN在内存中也同步了数据，就返回客户端success。

每个fsimage文件都是系统元数据的一个完整的持久化检查点（checkpoint）（后缀表示镜像中的最后一个事务）。写操作不更新这个数据，因为镜像文件通常为GB数量级，写到磁盘很慢。如果NameNode宕机，可以将最新fsimage加载到内存，同时执行edits log对应于该fsimage之后的操作，就可以重建元数据的状态。而这正是每次启动NameNode的时候NameNode要做的工作。

首席撩妹指导官

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
重启namenode速度慢，耗时很久加载fsimage问题解决办法

用户的操作是一个事务，每个操作NN都要先将操作记录到edits log中，如果给NN指定了多个目录，则在多个目录中都存在edits log文件，用户的操作要在多个目录中都写完成，才让NN同步数据到内存中。NameNode在内存中有文件系统的元数据，当edits log记录结束后，就更新内存中的元数据。-rw-r--r-- 1 root root 42 10月 9 14:49 edits_0000000000000000048-0000000000000000049。
复制链接

扫一扫