HDFS角色NameNode之Edits log文件分析

HDFS角色NameNode之Edits log文件分析

1 查看oiv命令

[root@node1 current]# hdfs oev --helpUsage: bin/hdfs oev [OPTIONS] -i INPUT_FILE -o OUTPUT_FILEOffline edits viewerParse a Hadoop edits log file INPUT_FILE and save resultsin OUTPUT_FILE.Required command line arguments:-i,--inputFile 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 Name of output file. If the specified file exists, it will be overwritten, format of the file is determined by -p optionOptional command line arguments:-p,--processor 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)

基本语法

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要做的工作。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。