hadoop-4 namenode和secondary namenode机制

namenode

• namenode用来管理集群中的元数据信息，每条元数据大概150byte
• 元数据信息存储namenode的内存中
• edits.log和fsimage存储在NameNode的本地磁盘中
• edits.log和fsimage加起来就是完整的元数据信息

namenode配置

namenode在hdfs-site.xml中配置，支持多路径存储配置。每个路径都会存储一份相同的数据

<property>
   <name>dfs.namenode.name.dir</name>
   <value>file1path,file2path...</value>
</property>

edits.log

• edits.log用来存储对元数据的操作日志.当内存中的元数据丢失后，可以根据edits.log的操作内容恢复内存中的元数据
• edits.log更新后，client才会看到最新的信息
• 开始的操作存放在edits.log中，因为fsimage内容非常大，直接放在fsimage中，加载太过消耗内存和cpu
  

查看edits.log

• 使用命令hdfs oev

hdfs oev -i edits_0000000000000009112-0000000000000009112 -o mytestedit.xml -p XML

fsimage

• fsimage是一定时间内NameNode中元数据的一个完整的镜像
  

查看fsimage

• 使用命令hdfs oiv

hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml

edits.log和fsimage配置

edits.log和fsimage配置在在hdfs-site.xml中

<property>
  <name>dfs.namenode.name.dir</name>
  <value></value>
</property>
<property>
   <name>dfs.namenode.edits.dir</name>
   <value></value>
</property>

NameNode工作机制

1. 第一次启动NameNode格式化后，创建fsimage和edits.log文件。如果不是第一次启动，直接加载镜像文件并通过edits.log文件回放。
2. client的每个增、删、改操作，都会对应一个事物，每个事物对应一个事物ID，事物ID递增。
3. namenode记录操作日志，存储在edits.log中
4. namenode在内存中数据进行增删改查

Secondary namenode

• 辅助NameNode队元数据进行管理,满足触发条件后，自动执行checkpoint减少人工干预
• 对NameNode进行冷备份
• 减少edits.log记录数，加快NN恢复速度(如某条元数据丢失，可以根据记录数较少的edits.log进行回访)
• namenode在机器挂掉之后，内存丢失。需要 SNN做可持久化处理，SNN保存在磁盘中
  SNN合并fsimage和edits.log时占用内存和NN差不多，因此一般将SNN和NN放在不同的机器上

Secondary namenode对namenode的备份

1.每过60s（hdfs-site.xml中设置）SNN询问NN是否需要做checkpoint
2.若满足checkpoint触发条件则开始执行checkpoint
3.NN滚动生成新的edits.log，用来存储正在执行的和将要执行的对元数据的操作。每次滚动生成有规则的递增的文件名
4.SNN通过http将最新的fsimage和滚动前的edits.log拷贝到SNN
5.SNN将拷贝过来的fsimage和edits.log加载到内存中合并
6.SNN将新生成的Fsimage落地到SNN本地磁盘，命名尾缀为.chkpoint的文件
7.SNN将生成的.checkpoint文件回传到NN，并重新命名为fsimage。

CheckPoint触发条件

触发条件在hdfs-site.xml中设置

1.两个备份时间差超过1小时

//默认设置3600秒
dfs.namenode.checkpoint.period 3600

2.edits.log中超过100万个事物

//默认设置100万次操作
dfs.namenode.checkpoint.txns 1000000

默认每隔60秒检查一次

dfs.namenode.checkpoint.check.period 60

利用Secondary namenode对数据进行恢复

• 利用SNN对NN进行恢复，实际上回丢失NN中未来的即备份的edits.log中的元数据信息。
• 利用SNN对NN进行恢复，太过笨拙，不采纳这种做法