Secondary NameNode:
作用:用于间歇性将NameNode EditLog记录的变化更新到Fsimage,从而限制EditLog文件的大小并保证NameNode的启动恢复时间在一定范围内(也就是不至于太久)。
前边的两篇关于HDFS的文章中提到两个与NameNode相关的两个文件Fsimage和EditLog文件
NameNode在启动时会读Fsimage加载HDFS所有DataNode的元数据信息以恢复HDFS的状态,并且需要将EditLog记录的修改应用于HDFS的状态。然后再将新的HDFS的状态写入到Fsimage文件。
可以看到,这一过程只在NameNode启动的时候进行,那么就会有如下问题:
所以可以看到,Secondary NameNode用于克服以上两个问题。
上边提到,Secondary NameNode间歇性的工作,那么这个间歇时间怎么确定,由以下两个参数确定,其实在前边的文章中已经写过
这一过程其实就是实施检查点checkpoint,检查点的存储目录结构和NameNode存储目录结构相同,以便于被主NameNode随时读取。
Checkpoint Node:
功能:间歇性的为NameNode的namespace实施检查点,从NameNode上下载Fsimage和EditLog文件,并在本地进行合并,合并完之后把新的Fsimage再传回NameNode上。
Checkpoint Node和web接口可通过以下两个参数配置
另外,间歇性checkpoint的确切时间配置也和Secondary NameNode相同,均为
dfs.namenode.checkpoint.period和dfs.namenode.checkpoint.txns,其表示的含义一致。
启用方式:bin/hdfs namenode -checkpoint
Backup Node:
其实,不管是Secondary NameNode、Checkpoint Node和Backup Node其作用都是解决前边描述的NameNode启动时所面临的问题的。
不同点在于
Backup Node会在内存中维护一份最新的文件系统的namespace的状态拷贝,并且这一状态拷贝总是跟NameNode同步。同时接收对文件系统edit操作的edits流,将其保存到本地磁盘,并将这些edits应用到文件系统的namespace状态中。
重点在于 在内存中 的 文件系统namespace的状态拷贝
不用像Secondary NameNode和Checkpoint Node那样要去NameNode下载Fsimage和edits,Backup node checkpoint进程工作时只需要将内存中的Fsimage保存到本地磁盘并重置EditLog即可,因此效率比较高。
配置了Backup Node就不需要Checkpoint Node。
配置了Backup Node就能以无需持久化的方式运行NameNode,持久化的工作完全委派给了Backup Node。启动是指定-importCheckpoint参数并且不用指定dfs.namenode.edits.dir。
Backup Node和web接口可通过以下两个参数配置
启用方式:bin/hdfs namenode -backup
Import Checkpoint
当Fsimage和EditLog文件丢失后,检查点文件就会被导入NameNode,需进行如下配置
创建一个空的文件目录 dfs.namenode.name.dir
指定checkpoint文件目录 dfs.namenode.checkpoint.dir
然后以带 -importCheckpoint 的参数启动NameNode,NameNode会加载checkpoint中的文件并保存到dfs.namenode.name.dir 目录中,当然,如果dfs.namenode.name.dir 目录不为空,NameNode会将加载的文件和dfs.namenode.name.dir目录下的文件比较是否一致,如果不一致,则报错。