hadoop的checkpoint
SecondaryNameNode
通过定时 查询 namenode上的edit logs 来保证 fsimage的及时更新 时刻复制 active的Namenode工作节点的快照 。
合并namenode 的 edit log 合并到 fsimage上
1.定时获取active状态的namenode节点的 edit logs 并更新 到 fsimage [Secondary自己的image快照 ](根据操作id来合并 从自己快照的最新的操作合并edits的操作只合并快照以后的)
2.一旦有了新的fsimage文件，它将其拷贝会 NameNode 中
3.NameNode 在下次重启会使用这个新的fsimage文件 减少重启时间
NameNode 的 edit log 中是什么时候发生改变
我们往DataNode放入文件时 ，DataNode 会和NameNode通信 告诉NameNode 什么文件的第几个block放在它那里 。NameNode会将其写入到edit log。
高可用集群
两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JournalNodes中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了。
运行JournalNodes的计算机。JournalNode守护程序相对轻量级，因此这些守护程序可以合理地与其他Hadoop守护程序并置在机器上，例如NameNodes，JobTracker或YARN ResourceManager。**注意：**必须至少有3个JournalNode守护进程，因为编辑日志修改必须写入大多数JN。这将允许系统容忍单个机器的故障。您也可以运行3个以上的JournalNodes，但为了实际增加系统可以容忍的失败次数，您应该运行奇数个JN（即3,5,7等）。请注意，当使用N JournalNodes运行时，系统最多可以容忍（N-1）/ 2个故障并继续正常运行。
JournalNode的工作原理
- hadoop.journalnode.edits.dir 配置Journal共享目录位置
- 只有活跃状态的节点有权对journal的共享目录进行更改 在更改时如果有半数目以上的Journalnode节点更改成功就是为更改成功。
- standby状态的NameNode有能力读取JournalNodes中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间
- 确保快速切换，standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个NameNode的地址，发送数据块位置信息和心跳给他们两个。
- 运行的JournalNode进程非常轻量，可以部署在其他的服务器上。注意：必须允许至少3个节点。当然可以运行更多，但是必须是奇数个，如3、5、7、9个等等。当运行N个节点时，系统可以容忍至少(N-1)/2(N至少为3)个节点失败而不影响正常运行。
- standby状态的NameNode可以完成checkpoint操作，因此没必要配置Secondary NameNode、CheckpointNode、BackupNode。如果真的配置了，还会报错。
