Hadoop Backup Node

Hadoop Backup Node

原文：http://share.blog.51cto.com/278008/1033994

li_qinshan 2012-10-22 20:19:01

元数据

要了解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 #XStar:执行文件应是bin/hadoop？

但是非常扯淡的是，虽然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版本，功能都还不一样！

Download

    1.0.X - current stable version, 1.0 release
    1.1.X - current beta version, 1.1 release
    2.X.X - current alpha version
    0.23.X - simmilar to 2.X.X but missing NN HA.
    0.22.X - does not include security
    0.20.203.X - old legacy stable version
    0.20.X - old legacy version

混乱的Apache Hadoop版本。

Namenode元数据恢复流程

启动Backup Node
在Namenode上清空dfs.name.dir下的文件(清除之前所有的元数据！！！)
在Namenode上执行命令：bin/hadoop namenode -importCheckpoint

其他元数据备份方案

hadoop还有哪些手段来保证namenode元数据的安全？

对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挂载到本地；

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，会导致这个问题。

XStar: 在hadoop-1.0.4的所有文件中都没搜到dfs.secondary.address和dfs.secondary.http.address选项。

恢复过程比较简，大略如下：

删除Namenode上的dfs.name.dir目录下所有的文件，如果配置了多个目录，要全部清空
复制Secondary Namenode上的fs.checkpoint.dir目录下的所有文件到Namenode的fs.checkpoint.dir目录下
在Namenode上执行bin/hadoop namenode -importCheckpoint
ctrl + c终止会话，删除NN上的scondary目录下的文件
正式启动Namenode：bin/hadoop-daemon.sh start namenode
bin/hadoop dfsadmin -safemode leave

上面的方法分几个步骤，很啰嗦，最简单的方法是：

把Secondary Namenode上的fs.checkpoint.dir目录下的current下的文件复制到Namenode的dfs.name.dir目录下的current目录中，然后启动namenode！

上面两个恢复的方法，我都是亲自试过，都是可以的。