Hadoop权威指南

详解namenode与secondarynamenode

一 、NameNode二、Secondary Namenode

一 、NameNode

1. namenode的目录结构 运行中的namenode有如下所示的目录结构 1.VERSION文件 是一个java属性文件，其中包含正在运行的HDFS的版本信息。文件一般包含以下内容 layoutVersion：是一个负整数，描述HDFS持久性数据结构的版本。namespaceID：是文件系统命名空间的唯一标识符，是在namenode首次格式化时创建的。clusterID：是将HDFS集群作为一个整体赋予的唯一标识符，对联邦HDFS非常重要，这里一个集群由多个命名空间组成，每个命名空间有由一个namanode管理。blockpoolID：是数据块池的唯一标识符，数据块池中包含了一个由namenode管理的命名空间中的所有文件。cTime：标记了namenode在存储系统创建的时间。storageType：说明该存储目录包含的是namenode的数据结构。in_use.lock：是一个锁文件，避免其他namenode实例同时使用同一个存储目录的情况。 2.镜像文件fsimage 和编辑日志 edits [面试重点] 客户端执行更新操作时，这些事务首先被记录到编辑日志(edits文件) 中。namenode在内存中维护文件系统的元数据；当编辑日志被修改时，相关元数据也同步更新。编辑日志在概念上是单个实体，但它体现为磁盘上的多个文件。每个文件称为一个**“段”(segement)**，名称由前缀edits组成，后缀指示出该文件所包含的事务ID。任一时刻只有一个文件处于打开可写的转态，在每个事务完成之后，在向客户端发送成功代码之前，文件都需要更新和同步。每个fsimage文件都是文件系统元数据的一个完整的永久性的检查点。并非每一个写操作都会更新fsimage文件，因为它是一个大型的文件(可高达几个GB)。如果频繁的执行写操作，会事系统运行极为缓慢。

每个fsimage文件包含文件系统中的所有目录和文件inode的序列化信息。每个inode是一个文件或者目录的元数据的内部描述方式。 数据块block存储在datanode中，但是fsimage文件并不描述datanode。但是namenode会将数据块的映射关系放在内存中。当DataNode加入集群时，namenode想datanode索取块列表以建立块映射关系。

如果namenode发生故障，最近的fsimage文件将被载入到内存中，以重构元数据的最近状态，再从相关点开始向前 执行**编辑日志(edits文件)**中的每个事务。如上所述，编辑日志edits会无限增长，尽管这种情况对于namenode的运行没有任何影响，但是由于需要恢复编辑日志的各种事务，namenode的重启操作比较耗时。在这段时间内，文件系统(HDFS)将处于离线状态，服务不可用。为了解决namenode重启耗时问题,引入了 secondarynamenode

二、Secondary Namenode

1. Secondary Namenode的目录结构

Secondary Namenode的检查点目录结构与namenode相同，这种设计的好处是，在主namenode发生故障时，可以从Secondary Namenode恢复数据。

2. Secondary Namenode作用

解决namenode重启耗时问题，减少namenode的工作压力，定期合并fsimage文件和编辑日志。为namenode内存中的文件元数据创建检查点。

3. 创建检查点，合并流程

① Secondary Namenode 请求 namenode停止使用正在进行中的edits文件，这样以后新的编辑操作记录到一个新文件中，namenode还会更新所有存储目录中的seen_txid文件。② Secondary Namenode 从 namenode获取最近 fsimage 和 edits文件。③ Secondary Namenode将 fsiamge文件载入内存，逐一执行edtis文件的事务操作。创建新的合并后的fsimage文件(_.ckpt结尾)④ Secondary Namenode 将新的fsimage发送回namenode ，namenode其保存为临时的.ckpt文件。⑤ namenode重新命名临时的fsimage文件，便于日后使用。最终，那么namenode拥有新的fsimage文件和一个小的正在进行中的edtis文件。

Secondary Namenode 和 namenode 拥有相近的内存需求，因此Secondary Namenode需要运行在一台专用机器上，与 namenode 分开。

4. 创建检查点的条件