1. SecondaryNameNode节点的主要功能是周期性将元数据节点的命名空间镜像文件和修改日志进行合并,以防日志文件过大。node
2.NameNode的镜像备份,若是NameNode宕机,能够从SecondaryNameNode恢复数据,但会存在数据丢失的状况(SecondaryNameNode最后一次读取镜像和修改日志到宕机中间的数据丢失)分布式
NameNode主要用来保存HDFS的元数据信息,好比命名空间信息、块信息等。为了保证效率,Namenode在启动的时候会将这些信息加载到内存中;同时,也会将这些信息持久化到硬盘中,一般会造成如下文件:空间命名镜像文件(fsimage)和修改日志文件(edits)。下图为NameNode的文件目录结构:oop
NameNode在启动时,会读取fsimage文件、合并edits文件。可是通常在集群中,namenode不多会重启,就致使了edits文件会逐渐变大,从而致使edits文件难以管理、重启变慢、edits文件损坏丢失过多数据等各类问题。
post
因此,Hadoop使用SecondaryNameNode来合并fsimage和edits文件,减小NameNode的工做量,提升Hadoop集群的可靠性。spa
SecondaryNameNode的工做流程以下:日志
SecondaryNameNode节点通知NameNode节点生成新的日志文件,之后的日志都写到新的日志文件中。orm
SecondaryNameNode节点用http get从NameNode节点得到fsimage文件及旧的日志文件。进程
SecondaryNameNode节点将fsimage文件加载到内存中,并执行日志文件中的操做,而后生成新的fsimage文件。内存
SecondaryNameNode节点将新的fsimage文件用http post传回NameNode节点上。get
NameNode节点能够将旧的fsimage文件及旧的日志文件,换为新的fsimage文件和新的日志文件(第一步生成的),而后更新fstime文件,写入这次checkpoint的时间。
这样NameNode节点中的fsimage文件保存了最新的checkpoint的元数据信息,日志文件也从新开始,不会变的很大了。
Secondary NameNode的检查点进程启动,是由两个配置参数控制的:
fs.checkpoint.period(新版本dfs.namenode.checkpoint.period),指定连续两次检查点的最大时间间隔, 默认值是1小时。
fs.checkpoint.size(新版本有变化,可是没找到变成什么了)定义了edits日志文件的最大值,一旦超过这个值会致使强制执行检查点(即便没到检查点的最大时间间隔)。默认值是64MB。
SecondaryNameNode运行在另一台非NameNode的 机器上
SecondaryNameNode进程默认是运行在NameNode节点的机器上的,若是这台机器出错,宕机,对恢复HDFS文件系统是很大的灾难,更好的方式是:将SecondaryNameNode的进程配置在另一台机器 上运行。至于为何要将SNN进程运行在一台非NameNode的 机器上,这主要出于两点考虑:
可扩展性: 建立一个新的HDFS的snapshot须要将namenode中load到内存的metadata信息所有拷贝一遍,这样的操做须要的内存就须要 和namenode占用的内存同样,因为分配给namenode进程的内存实际上是对HDFS文件系统的限制,若是分布式文件系统很是的大,那么namenode那台机器的内存就可能会被namenode进程所有占据。
容错性: 当snn建立一个checkpoint的时候,它会将checkpoint拷贝成metadata的几个拷贝。将这个操做运行到另一台机器,还能够提供分布式文件系统的容错性。