重启namenode速度慢，耗时很久加载fsimage问题解决办法
如果重启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
Optional command line arguments:
-o,--outputFile
file exists, it will be overwritten.
(output to stdout by default)
If the input file was an XML file, we
will also create an
-p,--processor
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 - -> 删除生成的
[root@node1 current]# cat /opt/hadoop-3.1.3/fsimage49.xml
部分显示结果如下:
16392
5
16385
DIRECTORY
1633749749273
root:supergroup:0755
9223372036854775807
-1
16386
DIRECTORY
user
1633748876034
root:supergroup:0755
-1
-1
16387
DIRECTORY
root
1633749176246
root:supergroup:0755
-1
-1
16388
FILE
hadoop-3.1.3.tar.gz
2
1633749066652
1633749010986
134217728
root:supergroup:0644
1073741825
1001
134217728
1073741826
1002
134217728
1073741827
1003
69640404
0
16389
FILE
test.txt
2
1633749176236
1633749175593
134217728
root:supergroup:0644
1073741828
1004
38
0
......
思考：观察发现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
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
file exists, it will be overwritten,
format of the file is determined
by -p option
Optional command line arguments:
-p,--processor
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
显示结果如下:
-64
OP_START_LOG_SEGMENT
1
OP_MKDIR
2
0
16386
/user
1633748876031
root
supergroup
493
OP_MKDIR
3
0
16387
/user/root
1633748876034
root
supergroup
493
OP_ADD
4
0
16388
/user/root/hadoop-3.1.3.tar.gz._COPYING_
2
1633749010986
1633749010986
134217728
DFSClient_NONMAPREDUCE_1752542758_1
192.168.20.101
true
root
supergroup
420
0
d021df05-6937-4fc7-9474-ffcbf27f0f14
3
OP_ALLOCATE_BLOCK_ID
5
1073741825
OP_SET_GENSTAMP_V2
6
1001
OP_ADD_BLOCK
7
/user/root/hadoop-3.1.3.tar.gz._COPYING_
1073741825
0
1001
-2
OP_END_LOG_SEGMENT
8
当文件系统客户端进行了写操作（例如创建或移动了文件），这个事务首先在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要做的工作。