大家好,又见面了,我是你们的朋友全栈君。
首先secondary namenode不是namenode的备份,而是辅助namenode管理的,分担namenode的压力。
此外,fsimage镜像文件读取数据到内存速度远快于读取edit日志文件,因此不能让edit的日志过大,所以定期把edit的内容合并到镜像磁盘中,这个合并过程就要用到secondary namenode。
fsimage:filesystem image 的简写,文件镜像。二进制文件,存储HDFS文件和目录元数据
Edits:二进制文件,每次保存fsimage之后到下次保存之间的所有HDFS操作,记录在Edit s文件。对文件的每一次操作,如打开、关闭、重命名文件和目录,都会生成一个edit记录。
fstime:二进制文件,fsimage做完一次checkpoint后,将最新的时间戳写入到fstime
Secondary NameNode:在HA cluster中又称为standby node
SecondaryNameNode工作原理
namenode首先来说对于每个文件操作,Hadoop并不会都写到fsimage,这样是很慢的,但是每次操作在提交后运行前先写入edits编辑日志,当edits编辑日志文件大小超过64M(参数可以设定),或者时间超过1小时(参数可以设定),secondarynamenode就会做checkpoint的工作,向namenode发送请求,这时namenode产生临时空文件edits.new,secondarynamenode就会读取namenode中的edits和fsimage,然后进行合并,合并成fsimage.ckpt检查点,然后通过HTTP方式将fsimage.ckpt发送到NameNode,然后NameNode把fsimage.ckpt重命名为fsimage(覆盖原有fsimage文件),同时edits.new重命名为edits(覆盖原有edits文件)。
注意这里edits.new是个临时文件,只有NameNode或者SecondaryNameNode正在做checkpoint的时候存在。
namenode启动读取fsimage原理
当重新启动namenode的时候,NameNode启动时根据checkpoint时间加载最新的fsimage和edits文件到内存里,然后创建文件edits.new临时空文件,然后合并生成fsimage.ckpt检查点,edits.new重命名为edits(覆盖原有edits文件),fsimage.ckpt重命名为fsimage(覆盖原有fsimage文件),然后更新fstime时间 和VERSION版本
使用secondary nameonde的原因:
Fsimage是HDFS存储元数据的文件,它不会在HDFS的每次文件操作(如打开、查询、创建、修改文件)后进行更新。而HDFS的每一次文件操作会增加一条edits记录。这样会出现edits记录不断增加的情况。
这种设计不影响系统的恢复能力。因为如果Namenode失败了,元数据的最新状态可以通过从磁盘中读出fsimage文件加载到内存中来进行重新恢复,然后重新执行edits记录中的操作,这也正是NameNode重新启动时所做的事情。但是如果edits记录很多,NameNode启动时会花很长的时间来运行edits记录中的操作。在此期间,HDFS文件系统是不可用的。
为了解决这个问题,Hadoop在NameNode之外的节点上运行了一个Secondary NameNode进程。Secondary NameNode定期从NameNode拷贝fsimage和edits记录到临时目录并合并成一个新的Fsimage,随后它将新的fsimage上传到NameNode,这样NameNode便会更新fsimage并删除原来的编辑日志。这个过程叫checkpoint。
Secondary NameNode不足之处:
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/106119.html原文链接:https://javaforall.cn