上篇说到了namenode启动过程中主要是加载fsimge,edits和接收datanode的block信息。这篇主要分析namenode加载fsimage和edits的整个过程。
首先,了解一下fsimage和edits是存放什么信息的。
在hdfs-default.xml中通过dfs.name.dir和dfs.name.edits.dir配置fsimage和edits的存放路径,默认的话是存放在一个路径下的。
FSImage类继承了Storage类,来看看Storage类的描述:
* Local storage information is stored in a separate file VERSION. * It contains type of the node, * the storage layout version, the namespace id, and * the fs state creation time.
可以看到,存储信息是放在一个单独的VERSION文件中,包含了节点类型,layoutversion,namespaceId和fs创建时间,那么看看集群实际上是不是这样的:
#Mon Nov 11 15:54:28 CST 2013 namespaceID=620542034 cTime=0 storageType=NAME_NODE layoutVersion=-32
除了VERSION外,Storage还会产生一个in_use.lock的文件,表示当前集群我已经在使用了,你们要想在启动使用是不可以的。
同样DataStorage(datanode上存放block的,配置文件项为dfs.data.dir) 也继承Storage,在datanode的dfs.data.dir目录下你也能看到这2个文件。
继续Fsimage,在下面有5个文件:
enum NameNodeFile { IMAGE ("fsimage"), TIME ("fstime"), EDITS ("edits"), IMAGE_NEW ("fsimage.ckpt"), EDITS_NEW ("edits.new"); private String fileName = null; private NameNodeFile(String name) {this.fileName = name;} String getName() {return fileName;} }
看看fsimage中的保存代码:
void saveFSImage(File newFile) throws IOException { FSNamesystem fsNamesys = FSNamesystem.getFSNamesystem(); FSDirectory fsDir = fsNamesys.dir; long startTime = FSNamesystem.now(); // // Write out data // 输出流写到fsimage文件中 DataOutputStream out = new DataOutputStream( new BufferedOutputStream( new FileOutputStream(newFile))); try { out.writeInt(FSConstants.LAYOUT_VERSION); out.writeInt(namespaceID); out.writeLong(fsDir.rootDir.numItemsInTree()); out.writeLong(fsNamesys.getGenerationStamp()); byte[] byteStore = new byte[4*FSConstants.MAX_PATH_LENGTH]; ByteBuffer strbuf = ByteBuffer.wrap(byteStore); // save the root saveINode2Image(strbuf, fsDir.rootDir, out); // save the rest of the nodes saveImage(strbuf, 0, fsDir.rootDir, out); fsNamesys.saveFilesUnderConstruction(out); fsNamesys.saveSecretManagerState(out); strbuf = null; } finally { out.close(); } LOG.info("Image file of size " + newFile.length() + " saved in " + (FSNamesystem.now() - startTime)/1000 + " seconds."); }
这里面除了一些基本信息外,最主要的就是inode的信息,就是存放文件和目录的基本信息,如时间,名称,使用者等。
关于inode更具体的信息,可以参看 http://blog.csdn.net/internetman/article/details/3850186
关于fsimage中的更详细格式,请参看 http://twtbgn.iteye.com/blog/1975256
在加载fsimage的过程中,会将fsimage和edits文件读入内存中进行合并,然后再写入到fsimage中去。在集群启动后,这件事就交给了secondarynamenode去做了。
相关推荐
之后,每次启动时,NameNode会加载Fsimage和所有Edits文件到内存,执行所有的编辑操作,以获得最新的元数据状态。 - **元数据操作**:当客户端发起文件系统操作(如创建、删除、修改文件或目录),NameNode记录这些...
这样,NameNode在下次启动时只需加载较小的Fsimage和较新的Edits文件,提高了启动速度。 **Fsimage和Edits解析工具:** Hadoop提供了 Fsimage 和 Edits 的解析工具,如`oiv`(Offline Image Viewer) 和 `oev`...
fsimage文件是Namenode在启动时加载的初始命名空间镜像,包含了HDFS的所有文件和目录结构。如果这个文件丢失或损坏,Namenode将无法启动。解决方法包括: - 从备份恢复:如果配置了Secondary Namenode或HDFS HA,...
hdfs oev -i edits_inprogress_0000000000000000128 -o ~/edit_inprogress.xml 这个命令将editLog文件转换为可读的XML格式。 小结 NameNode的职责是维护HDFS的命名空间和文件系统,包括维护fsImage文件和editLog...
- **非初次启动:** 如果是第二次及以后启动,则直接加载fsImage镜像文件和Edits日志到内存中。 - **客户端操作:** 客户端对文件系统的元数据进行的增删改操作会被记录到Edits文件中,并随后更新内存中的元数据。 - *...
SecondaryNameNode 节点会周期性的将 fsimage 和 edits 中记录的对 HDFS 的操作合并到一个previous.checkpoint 中,然后清空 edits。这样可以减少 NameNode 节点的启动时间,并确保 HDFS 集群的高可用性。 5. HDFS...
- **精简日志记录**:对于Log4j等日志记录工具,可以通过配置减少不必要的日志输出,或者选择性能更好的日志框架来替代,比如Logback。 #### 四、DFS实现优化 除了RPC框架之外,还需要关注HDFS的具体实现细节。...
在本文中,我们将深入探讨 Hadoop NameNode 的源码,了解其启动过程、配置加载、RPC 服务端创建、 Namenode 对象初始化等关键步骤。 启动 NameNode ---------------- 在 Hadoop 中,NameNode 的启动过程由 `main` ...
Hadoop 2.0 双 Namenode 双 Datanode 部署 Hadoop 是一个开源的大数据处理框架,它提供了分布式文件系统(HDFS)和Map/Reduce 计算框架。 在这个部署中,我们将使用 Hadoop 2.0 在两个 Ubuntu 服务器上部署双 ...
Secondary NameNode加载编辑日志和镜像文件到内存,并合并,生成新的镜像文件fsimage.chkpoint,然后拷贝fsimage.chkpoint到NameNode。NameNode将fsimage.chkpoint重新命名成fsimage。 三、HA NameNode工作原理 HA...
1. 启动时加载Fsimage和Edits到内存。 2. 接受客户端的元数据修改请求,更新Edits。 3. 内存中维护最新的元数据状态。 Secondary NameNode的作用: 1. 定期询问NameNode是否需要做CheckPoint(元数据快照)。 2. 当...
1. Secondary 通知 Namenode 切换 edits 文件。 2. Secondary 从 Namenode 获得 fsimage 和 edits(通过 HTTP)。 3. Secondary 将 fsimage 载入内存,然后开始合并 edits。 4. Secondary 将新的 fsimage 发回给 ...
【NameNode和Secondary NameNode详解】 在Hadoop分布式文件系统(HDFS)中,NameNode是核心组件,负责管理文件系统的命名空间(namespace)和文件块映射信息。它维护着文件系统树,记录所有文件和目录的信息,并且...
secondarynamenode并非namenode的热备份,它不会直接处理客户端的请求,其主要功能是定期合并namenode的编辑日志(edits)和命名空间镜像(FSImage),以防止编辑日志过大,减轻namenode的工作压力,并提供一种恢复...
`dfs.namenode.shared.edits.dir`指定了JournalNode的地址,用于存储NameNode的元数据变更日志。`dfs.ha.automatic-failover.enabled`启用自动故障切换功能,而`dfs.client.failover.proxy.provider`设置了客户端...
hdfs的namenode的元数据管理机制,简要画出了元数据管理的流程分析
4. **合并日志**:使用`CheckpointStorage`加载fsimage,应用edits日志,然后保存合并后的fsimage到硬盘。 5. **上传fsimage**:调用`putFSImage()`,通过HTTP将合并后的fsimage发送给NameNode。NameNode会验证检查...
Hadoop Namenode 恢复 Hadoop Namenode 是 Hadoop 分布式文件系统的核心组件之一,负责管理文件系统的命名空间。然而,在生产环境中,namenode 的崩溃可能会导致整个集群的不可用。因此,namenode 的恢复是非常重要...
在IT行业中,高可用性是关键,特别是在大数据处理领域,Hadoop作为分布式计算框架,其NameNode节点的稳定性至关重要。"hadoop namenode双机热备"是为确保Hadoop集群持续运行而采取的一种重要策略,通过双机热备可以...
1. 启动 NameNode,加载 edits 和 fsimage。 2. 客户端传入元数据的增删改查请求,进入 NameNode 的 edits 中。 3. fsimage 每隔一段时间备份 edits 中的数据。 4. SecondaryNameNode 启动,检查是否需要把 edits 中...