在hadoop1.x中，hdfs集群的namenode存在单点故障，一旦namenode出现故障，整个集群将不可用
secondary namenode并没有提供故障转移的能力，集群的可用性受到影响
secondary namenode只是周期性的把edit logs文件更新到fsimage，namenode在重启的时候会读取新的fsimage文件，以减少启动时间
namenode
namenode主要用来保存hdfs的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息是保存在内存中的
这些信息也会持久化到磁盘上一份，集群重启的时候会用到
fsimage：是namenode启动时对整个文件系统的快照
edit logs：在namenode启动后，对文件系统的改动记录
只有在namenode重启时，namenode才会把edit logs合并到fsimage，在集群中namenode是很少重启的，这样edit logs就会变的很大。
edit logs过大存在两个问题
1.edit logs过大，怎样去管理是一个挑战
2.namenode重启会花费大量时间
为了解决这些问题，引入了secondary namenode
secondary namenode的主要作用就是把edit logs中的内容合并到fsimage，只是namenode的一个助手，是namenode的一个检查节点
HA下的fsimage和editlog
1.共享存储(shared edits)
active namenode处理所有的操作请求（读写），standby namenode只同步状态
datanode会同时向两个namenode发送block报告和心跳
当满足一次checkpoint时（满足条件：离上一次checkpoint操作是否已经有一个小时，或者HDFS已经进行了100万次操作），standby nn进行一次合并操作。
active NN执行任何命名空间的修改都会持久化到一半以上的journalnodes上
而Standby NN负责观察edits log的变化，它能够读取从JNs中读取edits信息，并更新其内部的命名空间
一旦Active NN出现故障，Standby NN将会保证从JNs中读出了全部的Edits，然后切换成Active状态。
一次checkpoint过程
（1）、配置好HA后，客户端所有的更新操作将会写到JournalNodes节点的共享目录中
（2）、Active Namenode和Standby NameNode从JournalNodes的edits共享目录中同步edits到自己edits目录中；
（3）、Standby NameNode中的StandbyCheckpointer类会定期的检查合并的条件是否成立，如果成立会合并fsimage和edits文件；
（4）、Standby NameNode中的StandbyCheckpointer类合并完之后，将合并之后的fsimage上传到Active NameNode相应目录中；
（5）、Active NameNode接到最新的fsimage文件之后，将旧的fsimage和edits文件清理掉；
（6）、通过上面的几步，fsimage和edits文件就完成了合并，由于HA机制，会使得Standby NameNode和Active NameNode都拥有最新的fsimage和edits文件
（之前Hadoop 1.x的SecondaryNameNode中的fsimage和edits不是最新的）
如图：
2.如何防止namenode脑裂（两个namenode都处于active状态）
Journal Node通过epoch数来解决脑裂的问题，称为JournalNode fencing。具体工作原理如下：
1）当Namenode变成Active状态时，被分配一个整型的epoch数，这个epoch数是独一无二的，并且比之前所有Namenode持有的epoch number都高。
2）当Namenode向Journal Node发送消息的时候，同时也带上了epoch。当Journal Node收到消息时，将收到的epoch数与存储在本地的promised epoch比较，
如果收到的epoch比自己的大，则使用收到的epoch更新自己本地的epoch数。如果收到的比本地的epoch小，则拒绝请求。
3）edit log必须写入大部分节点才算成功，也就是其epoch要比大多数节点的epoch高。