在深入了解SecondaryNameNode之前，先来回顾一下NameNode是做什么的
NameNode：
NameNode主要是用来保存HDFS的元数据信息，比如命名空间信息、块信息等。当它运行的时候，这些信息时存在内存中的。但是这些信息也可以持久化到磁盘上。
1、fsimage ： 它是在NameNode启动时，对整个文件系统的快照。
2、edit logs： 它是在NameNode启动后，对文件系统的改动序列。
只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群（比如Ambari或ClouderManager）中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。
在这种情况下就会出现下面一些问题：
（1） edit logs文件会变的很大，怎么去管理这个文件是一个挑战？
（2） NameNode的重启会花费很长时间，因为有很多改动[在edit logs中要合并到fsimage文件上。]
（3） 如果NameNode挂掉了，那我们就丢失了很多改动，因为此时的fsimage文件非常旧。[在这个情况下丢失的改动应该是还在内存中但是没有写到edit logs的这部分。]
因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。
SecondaryNameNode：
SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。
Secondary NameNode是怎么工作的：
（1） 首先，它定时到NameNode去获取edit logs，并更新到fsimage上。[Secondary NameNode自己的fsimage]
（2） 一旦它有了新的fsimage文件，它将其拷贝回NameNode中。
（3） NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。
Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。它不是要取代掉NameNode也不是NameNode的备份。
NameNode和SecondaryNameNode通信模型
NameNode将对文件系统的改动追加保存到本地文件系统上的一个日志文件edits。当一个NameNode启动时，它首先从一个映像文件(fsimage)中读取HDFS的状态，接着执行日志文件中的编辑操作。然后将新的HDFS状态写人fsimage中，井使用个空的edits文件开始正常操作。因为NameNode只有在启动阶段才合并fsimage和edits，久而久之日志文件可能会变得非常庞大，特别是对于大型的集群。日志文件太大的另一个副作用是下一次NameNode启动会很长时间
日志与镜像的定期合并总共分六步：
1、NameNode管理着元数据信息，元数据信息会定期的刷到磁盘中，其中的两个文件是edits即操作日志文件和fsimage即元数据镜像文件，新的操作日志不会立即与fsimage进行合并，也不会刷到NameNode的内存中，而是会先写到edits中(因为合并需要消耗大量的资源)。当edits文件的大小达到一个临界值(默认是64MB)或者间隔一段时间(默认是1小时)的时候checkpoint会触发SecondaryNameNode进行工作。
2、当触发一个checkpoint操作时，NameNode会生成一个新的edits即上图中的edits.new文件，同时SecondaryNameNode会将edits文件和fsimage复制到本地。
3、SecondaryNameNode将本地的fsimage文件加载到内存中，然后再与edits文件进行合并生成一个新的fsimage文件即上图中的Fsimage.ckpt文件。
4、SecondaryNameNode将新生成的Fsimage.ckpt文件复制到NameNode节点。
5、在NameNode结点的edits.new文件和Fsimage.ckpt文件会替换掉原来的edits文件和fsimage文件，至此，刚好是一个轮回即在NameNode中又是edits和fsimage文件了。6、等待下一次checkpoint触发SecondaryNameNode进行工作，一直这样循环操作。