NameNode节点的升级/回滚/提交

最新推荐文章于 2022-12-21 15:58:23 发布

读程序的手艺人

最新推荐文章于 2022-12-21 15:58:23 发布

阅读量1.9k

点赞数

分类专栏： HDFS源码解析文章标签： image 磁盘

本文链接：https://blog.csdn.net/xhh198781/article/details/6991204

版权

HDFS源码解析专栏收录该内容

45 篇文章 6 订阅

订阅专栏

我记得在前面已经以regular方式为例详细的讲述了有关NameNode启动的过程，在开始本文的重点之前，我觉得还是有必要在简单的描述一下这个过程：

好了，再回到本文将要阐述的重点吧——NameNode节点的升级/回滚/提交，这一步实际上只发生在上面过程的第一步：加载FSImage+EditLog。前面我提过关系：文件->数据块持久化在本地磁盘上，所有对目录树的更新和文件名->数据块关系的修改，都必须能够持久化，为了保证每一次的修改不需要从新保存整个结构，HDFS使用操作日志来保存更新。先来看一下与FSImage+EditLog相关的文件：

目录current：

目录image：

in_use.lock的功能是防止其它的NameNode节点读取该目录；fsimage保存的是文件系统的目录(包括文件名->数据块映射)；edits则是保存文件数上的操作日志；fstime上一次新打开一个操作日志的时间(long)。image/fsimage是一个保护文件，防止0.13以前的版本启动出错(0.13以前的版本将fsimage存放在name/image目录下)。那么，NameNode在完成升级/回滚/提交时，对这些文件做了哪些操作呢？

在理想的情况下，上面的升级/回滚/提交可以顺利的完成，但是也难免会出现一些异常情况，特别是在进行上述操作的过程中，NameNode节点出现突然断电事件。不要紧，NameNode在启动加载FSImage+EditLog时有一个自动恢复的处理，当然这一个过程明显发生在真正load FSImage+EditLog之前。下面我们来看看NameNode节点在异常发生之后可以处于那些中间状态，以及它在下一次启动时是如何处理的。