您的位置:首页 > Web前端 > Node.js

Hadoop SecondaryNameNode

2016-03-23 00:00 218 查看
摘要: Hadoop SecondaryNameNode是NameNode的冷备份;合并fsimage和fsedits然后再发给namenode。本文介绍了SecondaryNameNode的工作原理。

作用

1. SecondaryNameNode节点的主要功能是周期性将元数据节点的命名空间镜像文件和修改日志进行合并,以防日志文件过大。

2.NameNode的镜像备份,如果NameNode宕机,可以从SecondaryNameNode恢复数据,但会存在数据丢失的情况(SecondaryNameNode最后一次读取镜像和修改日志到宕机中间的数据丢失)

工作原理

NameNode主要用来保存HDFS的元数据信息,比如命名空间信息、块信息等。为了保证效率,Namenode在启动的时候会将这些信息加载到内存中;同时,也会将这些信息持久化到硬盘中,通常会形成以下文件:空间命名镜像文件(fsimage)和修改日志文件(edits)。下图为NameNode的文件目录结构:



NameNode在启动时,会读取fsimage文件、合并edits文件。但是一般在集群中,namenode很少会重启,就导致了edits文件会逐渐变大,从而导致edits文件难以管理、重启变慢、edits文件损坏丢失过多数据等各种问题。



所以,Hadoop使用SecondaryNameNode来合并fsimage和edits文件,减少NameNode的工作量,提高Hadoop集群的可靠性。

SecondaryNameNode的工作流程如下:

SecondaryNameNode节点通知NameNode节点生成新的日志文件,以后的日志都写到新的日志文件中。

SecondaryNameNode节点用http get从NameNode节点获得fsimage文件及旧的日志文件。

SecondaryNameNode节点将fsimage文件加载到内存中,并执行日志文件中的操作,然后生成新的fsimage文件。

SecondaryNameNode节点将新的fsimage文件用http post传回NameNode节点上。

NameNode节点可以将旧的fsimage文件及旧的日志文件,换为新的fsimage文件和新的日志文件(第一步生成的),然后更新fstime文件,写入此次checkpoint的时间。

这样NameNode节点中的fsimage文件保存了最新的checkpoint的元数据信息,日志文件也重新开始,不会变的很大了。



Secondary NameNode的检查点进程启动,是由两个配置参数控制的:

fs.checkpoint.period(新版本dfs.namenode.checkpoint.period),指定连续两次检查点的最大时间间隔, 默认值是1小时。

fs.checkpoint.size(新版本有变化,但是没找到变成什么了)定义了edits日志文件的最大值,一旦超过这个值会导致强制执行检查点(即使没到检查点的最大时间间隔)。默认值是64MB。

SecondaryNameNode运行在另[b]一台非NameNode的 机器上[/b]

SecondaryNameNode进程默认是运行在NameNode节点的机器上的,如果这台机器出错,宕机,对恢复HDFS文件系统是很大的灾难,更好的方式是:将SecondaryNameNode的进程配置在另外一台机器 上运行。至于为什么要将SNN进程运行在一台非NameNode的 机器上,这主要出于两点考虑:

可扩展性: 创建一个新的HDFS的snapshot需要将namenode中load到内存的metadata信息全部拷贝一遍,这样的操作需要的内存就需要 和namenode占用的内存一样,由于分配给namenode进程的内存其实是对HDFS文件系统的限制,如果分布式文件系统非常的大,那么namenode那台机器的内存就可能会被namenode进程全部占据。

容错性: 当snn创建一个checkpoint的时候,它会将checkpoint拷贝成metadata的几个拷贝。将这个操作运行到另外一台机器,还可以提供分布式文件系统的容错性。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: