SecondaryNamenode

Posted 2021-01-29 sgs-sunguishi

一、NameNode  基础

 

1、NameNode元数据（metadata）

 

• 包含了整个HDFS文件系统的所有目录和文件信息。（储存在内存中）
• 对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。
• 对于文件来说包括数据块描述信息、修改时间、访问时间等；
• 内存中有一份完整的元数据（使得“读操作”更加快）（宕机会丢失）（实时更新）
• metadata=fsiamge+edits

 

2、NameNode两个重要文件

 

• fsimage ：元数据镜像文件（某一时刻metadata的快照）
• fsimage为二进制文件，保存了最新的元数据检查点，是edits经过secondaryNamenode合并后产生的高密度镜像文件。
• 磁盘中有一份完整的元数据镜像（fsimage）文件
• Block的位置信息不会保存到fsimage，由DataNode在向NameNode进行注册时重新加载和定期加载。

 

  2、edits ：元数据操作日志（针对目录树的修改操作）

• edits为二进制文件，记录对HDFS的各种更新操作，客户端执行所有的写操作都会被记录到editlog中。（比如创建文件，删除文件。打开、关闭、重命名文件和目录等）
• 新的操作日志不会立即与fsimage进行合并，而是会首先被记录在edits文件中。成功返回后才修改内存中的元数据（metadata），并向客户端返回，此时客户端才会看到最新信息。
• 当edits文件的大小达到一个临界值(默认是64MB)

　　　　<name>fs.checkpoint.size</name>

　　　　<value>67108864</value>

• 或者间隔一段时间(默认是1小时)的时候

　　　　<name>fs.checkpoint.period</name>

　　　　<value>3600</value>

　　Checkpoint会触发SecondaryNameNode进行工作。

 

二、SecondaryNamenode 存在的原因

 

• edits文件不断增大，如何存储和管理？
• 因为需要合并大量的edits文件生成fsimage，导致namenode重启时间过长。
• 一旦namenode宕机，用于恢复的fsiamge数据很旧，会造成大量数据的丢失。
• 解决方案：运行辅助namenode的Secondary NameNode，为主namenode内存中的文件系统元数据创建检查点（合并出一个fsiamge）。

 

三、Secondary NameNode

 

（一）日志与镜像的定期合并过程

1. 请求NameNode进行edit log的滚动，namenode会创建一个新的edit log（edits.new），新的元数据操作日志将记录到新生成的edit log文件
2. 通过http get方式将edits文件和fsimage复制到Secondary NameNode本地。
3. 加载fsimage到内存，然后执行edits中所有操作，并生成一个新的fsimage文件（fsimage.ckpt）
4. 通过http post方式，将fsimage.ckpt文件复制到NameNode；
5. NameNode将fsimage.ckpt文件重命名为fsimage并替换原来的fsimage文件，创建的edits.new将替代原来的edits文件，并且更新fsimage文件的检查点时间

 

（二）Secondary NameNode工作内容

• SecondaryNamenode并不能被用作Namenode也不是NameNode的备份（secondary namenode中没有元数据更新机制）

1. 备份fsimage元数据镜像文件

• SecondaryNamenode保存着合并后的fsimage镜像的一个备份，万一哪天Namenode宕机了，这个备份就可以用上了。
• 因为namenode和secondary namenode之间的信息交换不是实时的，所以在namenode宕机的时候也会有数据丢失，不过可以修复大量的数据。

2. 日志与镜像的定期合并（合并NameNode的edit logs到fsimage文件中）

• 每隔一段时间，secondary namenode将namenode上积累的edits（日志文件）和一个最新的fsimage下载到本地，并加载进内存进行合并，edits log文件往往很大。
• 它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并，以防止操作日志文件(edit log)变得过大。
• 通常，SecondaryNamenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和相当的内存。（因为fsimage是namenode的完整的镜像，内容很大，合并edit logs与fsimage需要加载fsimage到内存的话生成树状拓扑结构，这是非常耗内存和CPU。）

 

 

学习阶段 如有错误 恳请指正！！！