前言
本文隶属于专栏《1000个问题搞定大数据技术体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢!
本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系
正文
- 当 NameNode 启动时,从本地文件系统中读取 edits 和 FSImage 文件,将所有 edits 中的事务作用在内存中的 FSImage 上,并将这个新版本的 FSImage 从内存中写入到本地文件上,然后删除旧的 edits (这个过程称为检査点),最后等待各个 DataNode 向 NameNode 汇报文件块的信息来组装 block ID 映射关系。
- DataNode 启动时会扫描本地文件系统,产生一个本地文件对应的 HDFS 文件块的列表(每个文件块会对应一个本地文件),然后作为报告发送到 NameNode(这个报告称为块状态报告)。
- 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高可用原理是什么?