Hadoop Backup Node
要了解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挂载到本地；
