首先secondary namenode不是namenode的备份，而是辅助namenode管理的，分担namenode的压力。
fsimage：filesystem image 的简写,文件镜像。二进制文件，存储HDFS文件和目录元数据
Edits：二进制文件，每次保存fsimage之后到下次保存之间的所有HDFS操作，记录在Edit s文件。对文件的每一次操作，如打开、关闭、重命名文件和目录，都会生成一个edit记录。
fstime：二进制文件，fsimage做完一次checkpoint后，将最新的时间戳写入到fstime
Secondary NameNode：在HA cluster中又称为standby node
- 它的作用是：定期合并 fsimage 和 edits 日志，将 edits 日志文件大小控制在一个限度下
- namenode 响应 Secondary namenode 请求，将 edit log 推送给 Secondary namenode ， 开始重新写一个新的 edit log
- Secondary namenode 收到来自（HTTP方式) namenode 的 fsimage 文件和 edit log
- Secondary namenode 将 fsimage 加载到内存，应用 edit log ， 并生成一 个新的 fsimage 文件
- Secondary namenode 将新的 fsimage 推送（HTTP方式）给 Namenode
- Namenode 用新的 fsimage 取代旧的 fsimage ， 在 fstime 文件中记下检查 点发生的时
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不足之处：
因为Secondary namenode并不是实时进行checkpoint，所以当还没有进行下一次checkpoint的时候namenode出现了硬件故障同时又没有通过NFS存储元数据，那么Namenode中自上次checkpoint之后到故障发生期间的所有edits文件将丢失。因为此时secondary namenode存的只有上一次的fsimage文件，没有最新的edits文件，无法通过secondary namenode进行这段时间内的数据恢复。
Secondary NameNode不是NameNode的备份进程，如果NameNode宕机了，而SecondaryNameNode没有宕机，集群照样不能正常工作。如果要恢复集群工作，需要手动将Secondary NameNode上的fsimage文件拷贝到新的NameNode上面。