0.23和2.0分支支持federation,相当于将命名空间横向分片。
2.0分支NameNode支持HA, 有基于NFS和QJM(Quorum Journal Manager)
通过这样一番操作,就避免了Namenode的edits日志的无限增长,加速Namenode的启动过程。
但是Scondary Namenode有其自身的弱点,如checkpoint数据较旧,数据不一致等,新版本的hadoop已经把它放弃了,转而使用更加高效的Backup Node。
0.21版本后支持Backup Node,在内存中维护了一份从Namenode同步过来的fsimage,同时它还从namenode接收edits文件的日志流,并把它们持久化硬盘,Backup Node把收到的这些edits文件和内存中的fsimage文件进行合并,创建一份元数据备份。Backup Node高效的秘密就在这儿,它不需要从Namenode下载fsimage和edit,把内存中的元数据持久化到磁盘然后进行合并即可。
目前,hadoop集群只支持一个Backup Node,如果Backup Node出了问题,Hadoop元数据的备份机制也就失效了,所以hadoop计划在未来能支持多个Backup Node。
2.0分支NameNode支持HA, 有基于NFS和QJM(Quorum Journal Manager)
NameNode的冷备:
Secondary Namenode和Backup Node都是NN的冷备,切换需要手工切换IP。
通过这样一番操作,就避免了Namenode的edits日志的无限增长,加速Namenode的启动过程。
但是Scondary Namenode有其自身的弱点,如checkpoint数据较旧,数据不一致等,新版本的hadoop已经把它放弃了,转而使用更加高效的Backup Node。
0.21版本后支持Backup Node,在内存中维护了一份从Namenode同步过来的fsimage,同时它还从namenode接收edits文件的日志流,并把它们持久化硬盘,Backup Node把收到的这些edits文件和内存中的fsimage文件进行合并,创建一份元数据备份。Backup Node高效的秘密就在这儿,它不需要从Namenode下载fsimage和edit,把内存中的元数据持久化到磁盘然后进行合并即可。
目前,hadoop集群只支持一个Backup Node,如果Backup Node出了问题,Hadoop元数据的备份机制也就失效了,所以hadoop计划在未来能支持多个Backup Node。