要了解Hadoop Backup Node,要从Namenode的元数据说起。
我们都知道Namenode的元数据非常重要,如果元数据损坏,所有存储在datanode中的数据都读不出来了。另外,如果Namenode的元数据比较大,那么集群的启动速度非常慢。为了解决这两个问题,Hadoop弄了一个Secondary Namenode。
Namenode的元数据:
Hadoop Namenode元数据主要是两个文件:edits和fsimage。fsimage是HDFS的最新状态(截止到fsimage文件创建时间的最新状态)文件,而edits是自fsimage创建后的namespace操作日志。Namenode每次启动的时候,都要合并两个文件,按照edits的记录,把fsimage文件更新到最新。
如果是一个大的、比较繁忙的集群,它的edits文件增长会非常快,这样下次Namenode重启的过程会非常慢,因为它要进行大量的操作。为了加速启动过程,同时为了元数据的安全考虑,Hadoop搞了一个Secondary Namenode,它一般是一台独立的机器,内存大小与Namenode服务器相同。
Scondary Namenode:
Secondary Namenode定期地从Namenode上获取元数据。当它准备获取元数据的时候,就通知Namenode暂停写入edits文件。Namenode收到请求后停止写入edits文件,之后的log记录写入一个名为edits.new的文件。Scondary Namenode获取到元数据以后,把edits文件和fsimage文件在本机进行合并,创建出一个新的fsimage文件,然后把新的fsimage文件发送回Namenode。Namenode收到Secondary Namenode发回的fsimage后,就拿它覆盖掉原来的fsimage文件,并删除edits文件,把edits.new重命名为edits。
通过这样一番操作,就避免了Namenode的edits日志的无限增长,加速Namenode的启动过程。
但是Scondary Namenode有其自身的弱点,如checkpoint数据较旧,数据不一致等,新版本的hadoop已经把它放弃了,转而使用更加高效的Backup Node。
来看一下Backup Node:
Backup Node在内存中维护了一份从Namenode同步过来的fsimage,同时它还从namenode接收edits文件的日志流,并把它们持久化硬盘,Backup Node把收到的这些edits文件和内存中的fsimage文件进行合并,创建一份元数据备份。Backup Node高效的秘密就在这儿,它不需要从Namenode下载fsimage和edit,把内存中的元数据持久化到磁盘然后进行合并即可。
目前,hadoop集群只支持一个Backup Node,如果Backup Node出了问题,Hadoop元数据的备份机制也就失效了,所以hadoop计划在未来能支持多个Backup Node。
Backup Node的配置与启动:
和它有关的配置项,需要注意的是,Namenode和Backup Node都要配置这些选项:
hdfs-site.xml:dfs.backup.address、dfs.backup.http.address
core-site.xml:fs.checkpoint.period、fs.checkpoint.size、fs.checkpoint.dir、fs.checkpoint.edits.dir
启动:
在dfs.backup.address配置的节点上,运行bin/hdfs namenode -checkpoint
但是非常扯淡的是,虽然hadoop-1.0.3的官方hdfs用户文档中说放弃了Secondary Namenode,建议使用Backup Node,但在default配置文件中找不到关于backupnode的相关配置,反而secondary namenode的配置还保留着。到网上搜了一下,好像hadoop 1.0.3中并没有启用Backup Node,实际的原因是,hadoop 1.0.x完全是Apache的恶搞,Apache把hadoop 0.20.205直接命名成了hadoop 1.0!这么坑爹的事情都有!而Backup Node是Hadoop 0.21、0.22(0.23,它是0.22的超集)版本里的东西,这么多hadoop版本,功能都还不一样!
混乱的Apache Hadoop版本。
Namenode元数据恢复流程:
1、启动Backup Node
2、在Namenode上清空dfs.name.dir下的文件
3、在Namenode上执行命令:bin/hadoop namenode -importCheckpoint
hadoop还有哪些手段来保证namenode元数据的安全?
1) 对dfs.name.dir配置多个路径,保存一份元数据到远程主机。这样,加上Backup Node上的元数据,我们就有了三份元数据。我们的配置:
- <property>
- <name>dfs.name.dir</name>
- <value>/usr/local/hadoop/name,/home/hd_nn_remote_backup</value>
- </property>
需要注意的是,如果配置了多个路径,在恢复Namenode元数据时,要同时清空这些目录下的文件。
/home/hd_nn_remote_backup是一个远程主机目录,通过NFS挂载到本地;