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。

Hadoop Namenode元数据主要是两个文件:edits和fsimage。

fsimage是HDFS的最新状态(截止到fsimage文件创建时间的最新状态)文件;

edits是自fsimage创建后的namespace操作日志。

Namenode每次启动的时候,都要合并两个文件,按照edits的记录,把fsimage文件更新到最新。

如果是一个大的、比较繁忙的集群,它的edits文件增长会非常快,这样下次Namenode重启的过程会非常慢,因为它要进行大量的操作。

为了加速启动过程,同时为了元数据的安全考虑,Hadoop搞了一个Secondary Namenode,它一般是一台独立的机器,内存大小与Namenode服务器相同。

  1. Secondary Namenode定期地从Namenode上获取元数据。当它准备获取元数据的时候,就通知Namenode暂停写入edits文件。
  2. Namenode收到请求后停止写入edits文件,之后的log记录写入一个名为edits.new的文件。
  3. Scondary Namenode获取到元数据以后,把edits文件和fsimage文件在本机进行合并,创建出一个新的fsimage文件,然后把新的fsimage文件发送回Namenode。
  4. Namenode收到Secondary Namenode发回的fsimage后,就拿它覆盖掉原来的fsimage文件,并删除edits文件,把edits.new重命名为edits。

通过这样一番操作,就避免了Namenode的edits日志的无限增长,加速Namenode的启动过程。

但是Scondary Namenode有其自身的弱点,如checkpoint数据较旧,数据不一致等,新版本的hadoop已经把它放弃了,转而使用更加高效的Backup Node。

  1. Backup Node在内存中维护了一份从Namenode同步过来的fsimage,同时它还从namenode接收edits文件的日志流,并把它们持久化硬盘。
  2. Backup Node把收到的这些edits文件和内存中的fsimage文件进行合并,创建一份元数据备份。
  3. Backup Node高效的秘密就在这儿,它不需要从Namenode下载fsimage和edit,把内存中的元数据持久化到磁盘然后进行合并即可。

目前,hadoop集群只支持一个Backup Node,如果Backup Node出了问题,Hadoop元数据的备份机制也就失效了,所以hadoop计划在未来能支持多个Backup Node。

Backup Node的配置与启动

需要注意的是,Namenode和Backup Node都要配置这些选项:

  1. hdfs-site.xml:dfs.backup.address、dfs.backup.http.address
  2. 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版本。

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

其他元数据备份方案

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

需要注意的是,如果配置了多个路径,在恢复Namenode元数据时,要同时清空这些目录下的文件。

/home/hd_nn_remote_backup是一个远程主机目录,通过NFS挂载到本地;

一次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选项。

恢复过程比较简,大略如下:

  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!

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