Active NameNode(用以存放文件目录树,权限设置,副本数设置等),它会在指定目录下创建一个新的文件对象,比如access_20180101.logActive NameNode会不断修改元数据,而元数据是在内存的,为了防止宕机丢失,必须把它存在磁盘,但是频繁的修改磁盘数据,性能是很低的,这是大量的磁盘随机读写,所以有了上述图的方案Active NameNode会写一条edits log放到磁盘文件,不是直接修改磁盘文件内容,而是顺序追加,这个性能就高多了edits log还会写入JournalNodes集群,通过JournalNodes会把操作日志传到Standby NameNode,这就相当于是个备份服务,确保了Standby NameNode内存中的元数据和Active NameNode是一样的,而Standby NameNode每隔一段时间会把内存里的元数据写一份到磁盘的fsimage文件,这个文件就是全量的元数据了,不是日志记录Active NameNode,替换掉内存中的元数据,再清空掉Active NameNode所在磁盘上的edits log,重新开始记录日志Active NameNode突然宕机后,我们需要进行恢复,它的恢复是基于磁盘上的edits log的,和redis的aof相同的道理,它需要重新运行一遍日志中的所有命令,当时间长了后日志可能会很大,重启时间也就会很长;Standby NameNode的备份机制,就可以在节点重启时,直接从Standby NameNode的fsimage读取元数据备份,这就相当于redis的rdb恢复,速度是比较快的,读取完备份再从磁盘的edits log读取少量的操作日志执行恢复,就完全恢复到宕机前的状态了过眼云烟本尊这个评论者下留言,Thanks?(?ω?)?)参考:
用大白话告诉你小白都能看懂的Hadoop架构原理
大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问
原文:https://www.cnblogs.com/sky-chen/p/11346879.html