HDFS Namenode里的元数据

之前我写了一篇《 》,本文将解释一下这个集群下Namenode节点里的元数据。下一篇讲Datanode里的元数据。

通过下面的命令进入到namenode的容器里:

<code>$ docker exec -it namenode bash/<code>

hadoop/dfs/name 目录

<code>root@05f1f3fc4dd6:/# cd hadoop/dfs/name//<code>

in_use.lock

name 目录下面有一个in_use.lock文件和一个current目录。

<code>root@05f1f3fc4dd6:/hadoop/dfs/name# ls -al
total 16
drwxr-xr-x 3 root root 4096 Mar 22 07:34 .
drwxr-xr-x 3 root root 4096 Feb 4 16:28 ..
drwx------ 2 root root 4096 Mar 22 07:46 current
-rw-r--r-- 1 root root 16 Mar 22 07:46 in_use.lock/<code>

  • in_use.lock – 这是NameNode进程持有的锁文件,用于防止多个NameNode进程启动并同时修改这个name目录。
  • current 目录

    <code>root@05f1f3fc4dd6:/hadoop/dfs/name/current# ls -al
    total 5144
    drwx------ 2 root root 4096 Mar 22 07:46 .
    drwxr-xr-x 3 root root 4096 Mar 22 07:34 ..
    -rw-r--r-- 1 root root 213 Mar 22 07:34 VERSION
    -rw-r--r-- 1 root root 1048576 Mar 22 07:34 edits_0000000000000000001-0000000000000000001
    -rw-r--r-- 1 root root 1048576 Mar 22 07:38 edits_0000000000000000002-0000000000000000038
    -rw-r--r-- 1 root root 1048576 Mar 22 07:41 edits_0000000000000000039-0000000000000000059
    -rw-r--r-- 1 root root 1048576 Mar 22 07:42 edits_0000000000000000060-0000000000000000080
    -rw-r--r-- 1 root root 1048576 Mar 23 07:46 edits_inprogress_0000000000000000081
    -rw-r--r-- 1 root root 399 Mar 22 07:34 fsimage_0000000000000000000
    -rw-r--r-- 1 root root 62 Mar 22 07:34 fsimage_0000000000000000000.md5
    -rw-r--r-- 1 root root 3 Mar 22 07:46 seen_txid/<code>

    VERSION 文件

    <code>root@05f1f3fc4dd6:/hadoop/dfs/name/current# cat VERSION
    #Sun Mar 22 07:34:46 UTC 2020
    namespaceID=893392144
    clusterID=CID-566c43dd-60f2-41e0-8aa7-25e00a93eec0
    cTime=1584862486341
    storageType=NAME_NODE
    blockpoolID=BP-689076896-172.20.0.2-1584862486341
    layoutVersion=-65/<code>
    • layoutVersion - HDFS元数据格式的版本。当我们添加需要更改元数据格式的新功能时,我们将更改此数字。当HDFS软件使用的布局版本比此处当前跟踪的版本新时,需要升级HDFS。
    • namespaceID / clusterID / blockpoolID - 这些是HDFS集群的唯一标识符。标识符用于防止DataNode意外注册到属于其他群集的不正确的NameNode。这些标识符在联合部署中也特别重要。在联合部署中,有多个NameNode独立工作。每个NameNode服务于名称空间(namespaceID),并管理唯一的块集(blockpoolID)。clusterID将整个群集联系在一起成为单个逻辑单元。在集群中的所有节点上都是相同的。
    • storageType - 存储类型,NAME_NODE或JOURNALAL_NODE。
    • cTime - 文件系统状态的创建时间。HDFS升级的时候将更新此字段。

    文件系统镜像文件 fsimage

    fsimage_ – 其中包含完整的元数据镜像。每个fsimage文件还具有一个对应的.md5文件,其中包含MD5校验,HDFS使用该校验来防止磁盘损坏。

    编辑日志edit log,记录了在最近的fsimage之后进行的每个文件系统更改(文件创建,删除或修改)。

    edits_<start>_/<start> – 这些是不可修改的 edit log。每个edit log文件都包含文件名上的transaction ID范围内的所有编辑日志。在高可用性部署中,备用节点只能读取这些edit log。

    edits_inprogress_<start> – 这是当前正在进行的编辑日志。从<start>开始的所有变更都记录在此文件中。HDFS以1 MB的块大小在该文件中预先分配了空间,以提高效率。您可能会看到此文件的大小为1 MB的倍数。HDFS结束这个edit log的时候,会释放未使用空间,因此最终文件的大小将缩小。

    seen_txid

  • seen_txid - 它包含最后一个检查点(checkpoint,合并edits到fsimage中)的最后一个事务ID或编辑日志滚动roll(将当前edits_inprogress关闭生成完整的的edit log文件,并创建一个新的edits_inprogress)。请注意,这并不是NameNode接受的最后一个事务ID。该文件不会在每个事务来的时候更新,而只会在检查点checkpoint或编辑日志滚动roll的时候更新。该文件的目的是尝试识别启动期间是否缺少编辑edit。可以将NameNode配置为对fsimage和edits使用单独的目录。如果edits目录被意外删除,则自上一个检查点checkpoint以来的所有事务都将消失,NameNode有可能使用较老的fsimage启动。为了防止这种情况,NameNode启动时检查seen_txid以验证它至少要加载超过seen_txid的事物。如果无法做到,它将中止启动。

  • 本人将持续编写分布式系统设计相关的技术文章和视频,欢迎关注和讨论。


    分享到:


    相關文章: