NameNode

目录结构

Primary Namenode目录

• 运行中的所有Namenode节点中，namenode数据存放目录为dfs.namenode.name.dir
• dfs.namenode.name.dir可以指定多个目录，这些目录数据相同，增强可靠性
• 目录dfs.namenode.name.dir有以下结构

  ${dfs.namenode.name.dir}
  ├── current
  │   ├── edits_0000000000000000001-0000000000000000037
  │   ├── edits_0000000000000000038-0000000000000000039
  │   ├── ........
  │   ├── edits_****-***
  │   ├── ........
  │   ├── edits_0000000000000208442-0000000000000208443
  │   ├── edits_0000000000000208444-0000000000000208445
  │   ├── edits_inprogress_0000000000000208446
  │   ├── fsimage_0000000000000207763
  │   ├── fsimage_0000000000000207763.md5
  │   ├── fsimage_0000000000000208136
  │   ├── fsimage_0000000000000208136.md5
  │   ├── seen_txid
  │   └── VERSION
  └── in_use.lock
  

• VERSION文件是一个Java属性文件，其中包含正在运行的HDFS版本信息

  #Mon Jan 08 19:52:45 CST 2024
  namespaceID=856996238
  clusterID=ctyunns
  cTime=1704714765611
  storageType=NAME_NODE
  blockpoolID=BP-340244268-192.168.62.12-1704714765611
  layoutVersion=-66
  

• in_use.lock文件是一个锁文件
• edits_****-***是edit log，后缀是事务ID
• edits_inprogress_****是处于打开状态的edit log
• fsimage_****是元数据的完整永久checkpoint
  • dfs.namenode.num.checkpoints.retained

edit log

• 客户端的写操作（创建或者移动文件），会先记录到edit log
• 任何时刻只有一个edit log处于可写打开状态，即edits_inprogress_****
  • 事务完成后，该文件将被刷新和同步，随后返回客户端成功状态码
• namenode在内存中维护文件系统的metadata
  • 供客户端读取
  • 随着edit log被修改而修改

fsimage

• 在namenode的启动阶段，或当namenode发生故障时，会将最近的fsimage加载到内存中重构metadata，然后向前执行edit log中每个事务（仅执行edits_inprogress中的事务）

Secondary NameNode目录

• Secondary NameNode有两个目录

  • dfs.namenode.checkpoint.dir是临时目录，用于checkpointting

  • dfs.namenode.name.dir存在和Primary NameNode一样的fsimage文件，方便namenode主备切换

    ${dfs.namenode.name.dir}
    ├── current
    │   ├── edits_0000000000000010856-0000000000000010857
    │   ├── fsimage_0000000000000207763
    │   ├── fsimage_0000000000000207763.md5
    │   ├── fsimage_0000000000000208136
    │   ├── fsimage_0000000000000208136.md5
    │   ├── seen_txid
    │   └── VERSION
    └── in_use.lock
    

    • VERSION文件如下

      namespaceID=856996238
      clusterID=ctyunns
      cTime=1704714765611
      storageType=NAME_NODE
      blockpoolID=BP-340244268-192.168.62.12-1704714765611
      layoutVersion=-66
      

      这里blockpoolID与Primary NameNode一致

checkpointting

• 当edit log包含非常多的事务时，namenode的重启将非常慢，导致文件系统长时间离线

  如果没有S俄condary NameNode

• secondary namenode能够为primary namenode生产checkpoints，过程如下图
  
• 通过上面过程，primary namenode拥有最新的fsimage和更短的edit_inprogress文件
• 由于secondary namendoe需要将fsimage加载到内存，因此需要的内存与primary namenode相近
• 触发checkpointting的条件
  • secondary namenode每隔一小时（dfs.namenode.checkpoint.period，秒）进行checkpointting。
  • 如果从上checkpoint开始，edit log记录的事务数达到100万（dfs.namenode.checkpoint.txns），也会触发checkpointting
  • 事务数检查的频率是1分钟（dfs.namenode.checkpoint.check.period，秒）