Namenode当中的两个文件：edits和fsimage，fsimage文件包含了文件系统中的所有目录和文件inode的序列化信息。每个inode是一个文件或者目录的元数据的内部描述方式。因此该文件相当重要。fsimage文件是文件系统元数据的一个永久性检查点，并非每一个写操作都会更新这个文件，因为fsimage是一个大型文件，有时候甚至可高达几个G，如果频繁的对该文件进行写操作的话，会使系统运行极为缓慢。
同样的，namenode节点上的edits文件也无限的增长。尽管这种无限增长的情况对于namenode的运行来说是没有影响的。但是由于需要恢复非常长的编辑日志中的各项操作，namenode的重启操作会变得比较慢。（这里需要说明一下的是：集群当中，每一次重启namenode的时候，namenode都会加载并执行edits中的各项操作。）
因此hadoop采用的解决方案是：运行辅助namenode，为主namenode内存中的文件系统元数据创建检查点。SecondaryNameNode 检查点的具体步骤:
1、SecondaryNameNode 请求主 namenode 停止使用 edits 文件，暂时将新的操作记录到 edits.new 文件中；
2、SecondaryNameNode 以 http get 复制 主 namenode 中的 fsimage, edits 文件；
3、SecondaryNameNode 将 fsimage 载入到内存，并逐一执行 edits 文件中的操作，创建新的fsimage.ckpt 文件；
4、SecondaryNameNode 以 http post 方式将新的fsimage.ckpt 复制到主namenode.
5、主 namenode 将 fsimage.ckpt改为新的fsimag来替换原来旧的fsimage 文件，同时将 edits.new 文件重命名为 edits来替换原来旧的edits文件。并更新 fstime 文件来记录下次检查点时间。
6、SecondaryNameNode 保存最新检查点的目录与 NameNode 的目录结构相同。 所以 NameNode 可以在需要的时候读取 SecondaryNameNode上的检查点镜像。
Secondary Namenode定期地从Namenode上获取元数据。通过这样一番操作，就避免了Namenode的edits日志的无限增长，加速Namenode的启动过程。
讲到这里，很多人把secondarynamenode我无以为是第二个namenode，其实并不是这样子的，实际上secondarynamenode主要是为了分担主namendoe的fsimage和edits合并工作。本质上secondarynamenode是namenode一个组成部分与主namenode同时存在的。并且如果没有对Secondary Namenode进行参数设置的话，默认是会在namenode[0.0.0.0]节点上自行启动的。
但是Scondary Namenode有其自身的弱点，如checkpoint数据较旧，数据不一致等，新版本的hadoop已经把它放弃了，转而使用更加高效的Backup Node。
Hadoop2.x以后支持HA的部署，这个HA部署跟利用secondarynamenode来恢复主namenode是两种不同的方式。HA可以实现无缝接管，副节点随时处在待命的状态，主副namenode是可以自动切换。而利用secondarynamenode来恢复主namenode是需要手动恢复的，并且恢复的数据可能存在不一致性，其不一致性的原因主要是在检查点那一段时间内的数据可能会丢失，造成的数据不一致性。
在这里还需要注意一点：SecondaryNameNode的进程并不是一直处于开启状态的，SecondaryNameNode进程启动是由两个配置参数控制的。只有满足了这个两个条件之一才会启动，但是他的守护进程是一直在开启的。
（1）fs.checkpoint.period，指定连续两次检查点的最大时间间隔， 默认值是1小时。
（2）fs.checkpoint.size 定义了 edits 日志文件的最大值，一旦超过这个值会导致强制执行检查点（即使没到检查点的最大时间间隔）。默认值是64MB。
因此，创建检查点的过程不仅为主namenode创建检查点数据，使得SecondaryNameNode最终有一份检查点数据，这份数据可以用作namenode元数据的备份。
下面讨论一下SecondaryNameNode部署在那个节点上的问题：
如果SecondaryNameNode部署在datanode节点上的话，我们主要考虑的是cpu和内存的问题。下面我们来分析一下datanode内存使用情况：首先hadoop默认是给每一个进行分配1000M的内存，假如我们是八核的处理器，map和reducer的最大数目设置为7个，每个任务分配的是200M的内存，那么需要的最大内存为：14*400M，再加上datanode和tasktracker进行各1000M，共计：7600M。若datanode采用默认参数的话，默认map和reducer的最大数目是2.则对应的需要的内存是：2800M
如果SecondaryNameNode部署在namenode节点上的话，此时namenode内存消耗是：
仅仅一个namenode的进程：默认是1000M（但是实际情况可能不同）。但是这样部署都不是很合理，因为如果namenode磁盘坏掉，此时SecondaryNameNode的备份检查点数据也跟着坏掉，这样子就没有达到我们最终的目的。