据我所知，出于性能原因，fsimage 在启动时加载到内存中，并且任何进一步的事务都会添加到编辑日志中，而不是添加到 fsimage 中。
当namenode重新启动时，内存中的fsimage会被刷新。为了提高效率，辅助名称节点定期执行检查点来更新 fsimage，以便名称节点恢复更快。所有这些都很好。
但我不明白的一点是，
假设一个文件已经存在，并且有关该文件的信息位于内存中的 fsimage 中。
现在我将此文件移动到另一个位置，该位置在编辑日志中更新。
现在，当我尝试列出旧文件路径时，它抱怨它不存在或其他什么。
这是否意味着 namenode 也会查看编辑日志，这与内存中 fsimage 的目的相矛盾？或者它如何知道文件位置已更改？
答案是查看编辑日志中的信息。如果编辑日志中没有信息，这个问题对于我们将新文件写入 hdfs 的用例来说是正确的。当您的 namenode 正在运行时，如果您删除 fsimage 文件并尝试读取它能够读取的 hdfs 文件。
从正在运行的名称节点中删除 fsimage 文件不会导致读/写操作出现问题。当我们重新启动namenode时，会出现错误，提示找不到映像文件。
让我尝试提供更多解释来帮助您。
仅在启动时 hadoop 才会查找 fsimage 文件，如果它不存在，则 namenode 不会出现并记录用于格式化 namenode 的日志。
hadoop format -namenode 命令创建 fsimage 文件（如果存在编辑日志）。 namenode启动后，从编辑日志中获取文件元数据（如果在编辑日志中找不到信息，则通过fsimage文件搜索）。所以 fsimage 只是作为上次保存信息的检查点。这也是辅助节点保持编辑日志同步（1 小时/100 万个事务后）的原因之一，因此从最后一个检查点启动时不需要同步太多。
如果您打开安全模式（命令：hdfs dfsadmin -safemode Enter）并使用 saveNamespace（命令：hdfs dfsadmin -saveNamespace），它将显示下面提到的日志消息。
2014-07-05 15:03:13,195 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Saving image file /data/hadoop-namenode-data-temp/current/fsimage.ckpt_0000000000000000169 using no compression
2014-07-05 15:03:13,205 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Image file /data/hadoop-namenode-data-temp/current/fsimage.ckpt_0000000000000000169 of size 288 bytes saved in 0 seconds.
2014-07-05 15:03:13,213 INFO org.apache.hadoop.hdfs.server.namenode.NNStorageRetentionManager: Going to retain 2 images with txid >= 0
2014-07-05 15:03:13,237 INFO org.apache.hadoop.hdfs.server.namenode.FSEditLog: Starting log segment at 170
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
