一篇文章搞懂 HDFS 的启动流程

前言

本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系

正文

1. 当 NameNode 启动时，从本地文件系统中读取 edits 和 FSImage 文件，将所有 edits 中的事务作用在内存中的 FSImage 上，并将这个新版本的 FSImage 从内存中写入到本地文件上，然后删除旧的 edits (这个过程称为检査点)，最后等待各个 DataNode 向 NameNode 汇报文件块的信息来组装 block ID 映射关系。
2. DataNode 启动时会扫描本地文件系统，产生一个本地文件对应的 HDFS 文件块的列表(每个文件块会对应一个本地文件)，然后作为报告发送到 NameNode(这个报告称为块状态报告)。
3. NameNode 在接收到每个 DataNode 的块汇报信息后，将其和所在的 DataNode 信息等保存在内存中。

SecondaryNameNode 与 Hadoop HA

在 Hadoop1.x 中如果 NameNode失效，可以通过 SecondaryNameNode 中保存的 FSImage 和 edits 数据恢复出 NameNode 最近的状态。

为了加快 NameNode 重启速度，SecondaryNameNode 还会定期合并 edits。

关于 SecondaryNameNode 的更多内容请参考我的这篇博客——
SecondaryNameNode有什么作用？

在 Hadoop2.x 中不再使用 SecondaryNameNode 作为 NameNode 的恢复手段，而是采用了 HA 机制。

在 Hadoop 集群中有多台 NameNode，但只有一台 NameNode 处于 Active 状态，其余的均处于 Standby 状态。

Active NameNode 负责集群中所有客户端的操作，而 Standby NameNode 主要用于备用，它主要维持足够的状态，如果必要，可以提供快速的故障恢复。

为了让 Standby NameNode 的状态和 Active NameNode 保持同步，即元数据保持一致，会通过一组称作 JournalNode 的独立进程进行相互通信。

JournalNode至少部署在三个节点上，而且必须是奇数

当 Active NameNode 的命名空间有任何修改时，它需要持久化到一半以上的 JournalNode 上(通过 edits 持久化存储)。

Standby NameNode 有能力读取 JournalNode 中的变更信息，并且一直监控 edits 的变化，并把变化应用于自己的命名空间。

Standby NameNode 可以确保在集群出错时，命名空间状态已经完全同步，然后就可以切换到 Active 状态。

关于Hadoop HA的更多内容请参考我的这两篇博客——
1.HDFS的高可用和联邦是什么？
2.HDFS高可用原理是什么？