Hadoop 1.x 的 Secondary NameNode，和 Hadoop 2.x 的 NameNode HA。
NameNode
NameNode主要是用来保存HDFS的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。
上面的这张图片展示了NameNode怎么把元数据保存到磁盘上的。这里有两个不同的文件：
- fsimage - 它是在NameNode启动时对整个文件系统的快照
- edit logs - 它是在NameNode启动后，对文件系统的改动序列
只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。在这种情况下就会出现下面一些问题：
- edit logs文件会变的很大，怎么去管理这个文件是一个挑战。
- NameNode的重启会花费很长时间，因为有很多改动[笔者注:在edit logs中]要合并到fsimage文件上。
- 如果NameNode挂掉了，那我们就丢失了很多改动因为此时的fsimage文件非常旧。
为了克服这个问题，需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。
现在我们明白了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。那么，这些跟Secondary NameNode又有什么关系呢？
Secondary NameNode
SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。
下面我们来看一下SecondaryNameNode工作的流程，如下图：
1.NameNode管理着元数据信息，元数据信息会定期的刷到磁盘中，其中的两个文件是edits即操作日志文件和fsimage即元数据镜像文件，新的操作日志不会立即与fsimage进行合并，也不会刷到NameNode的内存中，而是会先写到edits中(因为合并需要消耗大量的资源)。当edits文件的大小达到一个临界值(默认是64MB)或者间隔一段时间(默认是1小时)的时候checkpoint会触发SecondaryNameNode进行工作。
2.当触发一个checkpoint操作时，NameNode会生成一个新的edits即上图中的edits.new文件，同时SecondaryNameNode会将edits文件和fsimage复制到本地。
3.Secondary NameNode将本地的fsimage文件加载到内存中，然后再与edits文件进行合并生成一个新的fsimage文件即上图中的Fsimage.ckpt文件。
4.SecondaryNameNode将新生成的Fsimage.ckpt文件复制到NameNode节点。
5.在NameNode结点的edits.new文件和Fsimage.ckpt文件会替换掉原来的edits文件和fsimage文件，至此，刚好一个轮回即在NameNode中又是edits和fsimage文件了。
6.等待下一次checkpoint触发Secondary NameNode进行工作，一直这样循环操作。
说明：新生成的edits.new应该是一个空文件，此时若Name Node元信息出现了改动，则会被写入到edits.new中。
Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是Name Node的一个助手节点。这也是它在社区内被认为是检查点节点的原因。现在，我们明白了Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起，让我们养成一个习惯，称呼它为检查点节点吧。
Secondary NameNode是hadoop1.x中HDFS HA的一个解决方案，在实际的生产系统中只能减少系统宕机时丢失的数据量，减少系统重启时间，但是并不能降低NameNode宕机风险。在hadoop2.x中都是采用NameNode HA的解决方案！
Import Checkpoint（恢复数据）
如果主节点挂掉了，硬盘数据需要时间恢复或者不能恢复了，现在又想立刻恢复HDFS，这个时候就可以import checkpoint。步骤如下：
- 拿一台和原来机器一样的机器，包括配置和文件，一般来说最快的是拿你节点机器中的一台，立马能用（部分配置要改成NameNode的配置）
- 创建一个空的文件夹，该文件夹就是配置文件中dfs.name.dir所指向的文件夹。（或者删除 namenode主节点的metadata配置目录）
- 拷贝你的secondary NameNode checkpoint出来的文件，到某个文件夹，该文件夹为fs.checkpoint.dir指向的文件夹
- 执行命令bin/hadoop namenode -importCheckpoint
这样NameNode会读取checkpoint文件，保存到dfs.name.dir。但是如果你的dfs.name.dir包含合法的fsimage，是会执行失败的。因为NameNode会检查fs.checkpoint.dir目录下镜像的一致性，但是不会去改动它。
NameNode HA（高可用）
在hadoop 1.x 中NameNode存在一个单点故障问题，也就是说如果NameNode所在的机器发生故障，那么整个集群就将不可用(hadoop1中有个SecorndaryNameNode，但是它并不是NameNode的备份，它只是namenode的一个助理，协助namenode工作，对fsimage和edits文件进行合并，并推送给NameNode，防止因edits文件过大，导致NameNode重启变得很慢),这是hadoop1的不可靠实现。
在Hadoop2中这个问题得以解决，Hadoop2中的高可靠性是指同时启动NameNode,其中一个处于active工作状态，另外一个处于随时待命standby状态。这样，当一个NameNode所在的服务器宕机时，可以在数据不丢失的情况下， 手工或者自动切换到另一个NameNode提供服务。
这些NameNode之间通过共享数据，保证数据的状态一致。多个NameNode之间共享数据，可以通过Network File System或者Quorum Journal Node。前者是通过Ｌinux共享的文件系统，属于操作系统的配置；后者是Ｈadoop自身的东西，属于软件的配置。
我们这里讲述使用Quorum Journal Node的配置方式，方式是手工切换。
集群启动时，可以同时启动2个NameNode。这些NameNode只有一个是active的，另一个属于standby状态。active状态意味着提供服务，standby状态意味着处于休眠状态，只进行数据同步，时刻准备着提供服务，如下图所示。
架构
在一个典型的HA集群中，每个NameNode是一台独立的服务器。在任一时刻，只有一个NameNode处于active状态，另一个处于standby状态。其中，active状态的NameNode负责所有的客户端操作，standby状态的NameNode处于从属地位，维护着数据状态，随时准备切换。
两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了，如下图所示。
为了确保快速切换，standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个NameNode的地址，发送数据块位置信息和心跳给他们两个。
对于HA集群而言，确保同一时刻只有一个NameNode处于active状态是至关重要的。否则，两个NameNode的数据状态就会产生分歧，可能丢失数据，或者产生错误的结果。为了保证这点，JNs必须确保同一时刻只有一个NameNode可以向自己写数据。
硬件资源
为了部署HA集群，应该准备以下事情：
- NameNode服务器：运行NameNode的服务器应该有相同的硬件配置。
- JournalNode服务器：运行的JournalNode进程非常轻量，可以部署在其他的服务器上。注意：必须允许至少3个节点。当然可以运行更多，但是必须是奇数个，如3、5、7、9个等等。当运行N个节点时，系统可以容忍至少(N-1)/2个节点失败而不影响正常运行。
在HA集群中，standby状态的NameNode可以完成checkpoint操作，因此没必要配置Secondary NameNode、CheckpointNode、BackupNode。如果真的配置了，还会报错。