那么这样问题又来了，如果我的系统运行了很长很长时间，edits特别大，所以在下一次namenode重启时，要重放edits需要花费很长很长时间。可以不可以在系统运行期间定期就把fsimage和edits同步一次呢，让edits始终保持很小的数据量，以便于namenode快速重启。在1.x版本中引进了secondarynamenode的解决方案：
（1）、SecondaryNamenode会定期的和NameNode通信，请求其停止使用edits文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别；
（2）、SecondaryNamenode通过HTTP GET方式从NameNode上获取到fsimage和edits文件，并下载到本地的相应目录下；
（3）、SecondaryNamenode将下载下来的fsimage载入到内存，然后一条一条地执行edits文件中的各项更新操作，使得内存中的fsimage保存最新；这个过程就是edits和fsimage文件合并；
（4）、SecondaryNamenode执行完（3）操作之后，会通过post方式将新的fsimage文件发送到NameNode节点上
（5）、NameNode将从SecondaryNamenode接收到的新的fsimage替换旧的fsimage文件，同时将edit.new替换edits文件，通过这个过程edits就变小了！
在hadoop 2.x 基于HA的namenode中对元数据的管理做了进一步的改进。取消了fsimage、edits和secondarnamenode机制。在HA中，通过从节点（nns）和一组称作JournalNodes的进程来保证元数据的稳定性。在HA中，JournalNodes主要作用是保持nns和nna之间的通信和数据同步。工作原理为：主节点nna（namenode active ）始终处于工作的状态，当元数据发生变化时，主节点通知journalnode进程，nns从节点从journalnode进程中读取元数据的变化并在自身的自身中进行重放，时刻关注主节点元数据的变化，当主节点嗝屁了之后，从节点以完美的元数据同步接管主节点的相关任务和应用请求。
H
