fsimage 和editelog的问题

最新推荐文章于 2022-02-23 21:30:00 发布

chouchi4012

最新推荐文章于 2022-02-23 21:30:00 发布

阅读量198

点赞数

文章标签：数据库大数据

原文链接：https://my.oschina.net/u/270950/blog/170471

版权

在hadoopor论坛里看到这样的问题，这里做个回答。

我有一个疑问，在namenode的内存中记录了fsimsage信息，
但是内存中的fsimage元数据是在namemode启动时去合并本地的
editlog和fsimage得到的，这样的话就存在以下问题：
1. 如果namenode一直不重新启动的话
那么如何保证内存中的fsimage是最新的呢
2.在最新的hdfs版本中是否支持周期性的去合并本地editlog和fsimage信息？
3.本地的fsimage中的元数据是在什么时候写入的？
新建文件的时候会向editlog中记录日志
是在这个时候把元数据写入到fsimage中的吗？
如果是，那么editlog为什么还要和fsimage进行合并？
因为editlog中记录的元数据，在fsimage中都已经有了。
那位能帮忙解答下，不胜感激。

解答：
1：问题本身就有问题，fsimage是存于硬盘的元数据检查点，Hadoop不会对每个文件操作都写出到fsimage，这样是很慢的，但是每个文件操作都会在提交后运行前先写入edits编辑日志，这样在namenode出现故障后，就会将fsimage和edits编辑日志结合读入内存，重建元数据信息。具体的检查点和日志滚动，可以参见数据库的检查点和Apache的日志滚动技术。

2：上面也说过，参考数据库的检查点知识。为了避免edits编辑日志的无限制扩大，secondary namenode 就回按照时间阈值（比如1小时）或者按大小阈值（edits编辑日志文件大小超过64M，这些参数都可以设置）“周期性”的读取namenode中的edits和fsimage重构fsimage检查点，同时在namenode中进行edits的滚动，来解决这个问题。

3：正确理解了namenode和secondary namenode的机制就明白了fsimage是“周期性”的进行更新的。
z Hadoop secondary namenode fsimage检查点更新

在NameNode节点启动之前，我们一般会在配置文件hdfs-default.xml中分别配置文件fsImage、edits所在的路径，它们对应配置文件中的项dsf.name.dir、dfs.name.edits.dir。同时，也可以同时配置多个fsImage、edits的路径，其中fsImage和edits也可以有相同的路径。无论是文件fsImage的路径还是文件edits的路径，NameNode都会把它抽象成一个StorageDirectory对象：

因此，每一fsimage的路径被实例化为IMAGE类型的StorageDirectory对象，每一个edits的路径被实例化为EDITS类型的StorageDirectory对象，而既是fsimage又是edits的路径则被实例化为IMAGE_AND_EDITS类型的StorageDirectory对象。对于配置了多个fsimage和edits的路径的启动，NameNode并不会加载加载，而是从IMAGE类型的StorageDirectory集合中挑选一个最新版本的fsimage文件，从EDITS类型的StorageDirectory的集合中挑选一个最新版本的edits文件，当然IMAGE_AND_EDITS类型的StorageDirectory既可以看作是IMAGE类型的，也可以看作是EDITS类型的。至于如何判断一个StorageDirectory是不是最新的，主要是根据StorageDirectory中fstime文件存放的时间戳来确定的。在选取最新的fsimage、edits文件之后还要保证他们的版本相同，否则整个NameNode节点的启动过程失败。下面还是用一张图来描述整个过程吧！

在理想的情况下，上述过程没有半点问题，但是如果在这一过程中突然出现了宕机或者是断电的异常情况而被迫中断，特别是在保存最新的目录树的时候，那么NameNode在重启之后又是如何恢复的呢？实际上，在上面的流程图中，我故意遗漏了一个相当重要的过程——checkpoint的恢复过程。这个过程在加载当前最新的fsimage文件之前，主要是恢复最新的fsimage、edits目录。