要了解Hadoop Backup Node，要从Namenode的元数据说起。

我们都知道Namenode的元数据非常重要，如果元数据损坏，所有存储在datanode中的数据都读不出来了。另外，如果Namenode的元数据比较大，那么集群的启动速度非常慢。为了解决这两个问题，Hadoop弄了一个Secondary Namenode。

Namenode的元数据：
Hadoop Namenode元数据主要是两个文件：edits和fsp_w_picpath。fsp_w_picpath是HDFS的最新状态（截止到fsp_w_picpath文件创建时间的最新状态）文件，而edits是自fsp_w_picpath创建后的namespace操作日志。Namenode每次启动的时候，都要合并两个文件，按照edits的记录，把fsp_w_picpath文件更新到最新。

如果是一个大的、比较繁忙的集群，它的edits文件增长会非常快，这样下次Namenode重启的过程会非常慢，因为它要进行大量的操作。为了加速启动过程，同时为了元数据的安全考虑，Hadoop搞了一个Secondary Namenode，它一般是一台独立的机器，内存大小与Namenode服务器相同。

Scondary Namenode：
Secondary Namenode定期地从Namenode上获取元数据。当它准备获取元数据的时候，就通知Namenode暂停写入edits文件。Namenode收到请求后停止写入edits文件，之后的log记录写入一个名为edits.new的文件。Scondary Namenode获取到元数据以后，把edits文件和fsp_w_picpath文件在本机进行合并，创建出一个新的fsp_w_picpath文件，然后把新的fsp_w_picpath文件发送回Namenode。Namenode收到Secondary Namenode发回的fsp_w_picpath后，就拿它覆盖掉原来的fsp_w_picpath文件，并删除edits文件，把edits.new重命名为edits。
通过这样一番操作，就避免了Namenode的edits日志的无限增长，加速Namenode的启动过程。
但是Scondary Namenode有其自身的弱点，如checkpoint数据较旧，数据不一致等，新版本的hadoop已经把它放弃了，转而使用更加高效的Backup Node。

来看一下Backup Node：
Backup Node在内存中维护了一份从Namenode同步过来的fsp_w_picpath，同时它还从namenode接收edits文件的日志流，并把它们持久化硬盘，Backup Node把收到的这些edits文件和内存中的fsp_w_picpath文件进行合并，创建一份元数据备份。Backup Node高效的秘密就在这儿，它不需要从Namenode下载fsp_w_picpath和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上的元数据，我们就有了三份元数据。我们的配置：

 
  
  1. <property> 
  2. <name>dfs.name.dir</name> 
  3. <value>/usr/local/hadoop/name,/home/hd_nn_remote_backup</value>
  4. </property> 
 
  
  
 
  
 需要注意的是，如果配置了多个路径，在恢复Namenode元数据时，要同时清空这些目录下的文件。
 /home/hd_nn_remote_backup是一个远程主机目录，通过NFS挂载到本地；
 
  
 
   2) Namenode热备。目前的热备方案有Facebook的Avatar、DRBD等。  
  
 
  

      
  
 
  
 
   一次Namenode恢复实践： 
  
 
  
 
   我们的环境是RHEL 5.6，Apache Hadoop 1.0.3。由于未采用Backup Node，我们仍然使用的是Secondary Namenode的配置，所以跟Backup Node的数据恢复有点不太一样。 
  
 
  
 
   上周五，由于服务器在重启时忘记停掉Hadoop集群，导致了Namenode元数据损坏，所以进行了一次恢复操作。遗憾的是，由于Secondary Namenode获取Namenode元数据时出了问题，而我们没有及时注意到这个情况，导致恢复出来的数据丢失了几天的量。这里提醒大家一下，到Namenode机器的dfs.name.dir目录下看一看，如果Hadoop把大量的日志记录在edits.new，而不是edits文件，那你就要小心了，可能Secondary Namenode那边出了状况，要及时查看日志，解决问题。一般地，如果未配置dfs.secondary.address和dfs.secondary.http.address，会导致这个问题。 
  
 
  
 
   恢复过程比较简，大略如下： 
  
 
  
 
   1、删除Namenode上的dfs.name.dir目录下所有的文件，如果配置了多个目录，要全部清空 
  
 
  
 
   2、复制Secondary Namenode上的fs.checkpoint.dir目录下的所有文件到Namenode的fs.checkpoint.dir目录下 
  
 
  
 
   3、在Namenode上执行bin/hadoop namenode -importCheckpoint 
  
 
  
 
   4、ctrl + c终止会话，删除NN上的scondary目录下的文件 
  
 
  
 
   5、正式启动Namenode：bin/hadoop-daemon.sh start namenode 
  
 
  
 
   6、bin/hadoop dfsadmin -safemode leave 
  
 
  
 
     
  
 
  
 
   上面的方法分几个步骤，很啰嗦，最简单的方法是：把Secondary Namenode上的fs.checkpoint.dir目录下的current下的文件复制到Namenode的dfs.name.dir目录下的current目录中，然后启动namenode！ 
  
 
  
 
   上面两个恢复的方法，我都是亲自试过，都是可以的。