第5章 NameNode和SecondaryNameNode

留不住斜阳

已于 2022-06-02 16:13:05 修改

阅读量1k

点赞数

分类专栏： HDFS 大数据文章标签： hdfs namenode SNN

于 2022-06-02 10:24:32 首次发布

本文链接：https://blog.csdn.net/lubin2016/article/details/125086412

版权

5.1.NameNode

NameNode 负责管理文件系统的命名空间以及客户端对文件的访问。当客户端请求数据时，从 NameNode 获取文件的元数据信息，具体的数据传输不经过 NameNode，而是直接与具体的 DataNode 进行交互。
文件的元数据信息记录了文件系统中的文件名和目录名，以及它们之间的层级关系，同时也记录了每个文件所属目录、所有者及其权限，甚至还记录每个文件由哪些块组成，这些元数据信息记录在 fsimage 中，当系统初次启动时，NameNode 将读取 fsimage 中的信息并保存到内存中。
文件块的位置信息是由 NameNode 启动后从每个 DataNode 获取并保存在内存当中的，这样既减少了 NameNode 的启动时间，又减少了读取数据的查询时间，提高了整个系统的效率。
内存中的元数据发生更新，磁盘中的fsimage也需要同时更新，才能保证数据的一致性。但是，如果内存中的元数据每更新一次，就同步到磁盘，效率会非常低下。

5.2.SecondaryNameNode

SecondaryNameNode 不是 NameNode 的备份
SecondaryNameNode 会定时定量的把集群中的 Edits 文件转化为 Fsimage 文件，来保证 NameNode 中数据的可靠性

5.3.NN和SNN工作机制

NameNode存储文件系统目录树的信息，而目录树的信息则存放在fsimage文件中，当NameNode启动的时候首先读取整个fsimage文件，将信息装载到内存
edits文件存储日志信息，在HDFS上所有更新操作，包括增加，删除，修改等都会保存到edits文件中，并不会同步到fsimage中，当NameNode关闭的时候，也不会将fsimage和edits进行合并。
注意：客户端的操作首先写入到edits文件中，然后操作内存中的数据
所以当NameNode启动的时候，首先装载fsimage文件到内存中，然后按照edits中的记录执行一遍所有记录的操作，最后将内存中最新的fsimage保存到磁盘上，之后重新启用新的edits文件记录后续更新操作。
如果该合并过程只由NameNode去做，那么就会增加NameNode的压力，因为不仅需要处理合并还要处理客户端的请求
基于上述NameNode中fsimage和edits合并只在NameNode启动的时候才会进行，但是生产环境下，重启NameNode的时候edits往往非常大，而edits中保存的是操作，往往也存在许多重复性操作，意味着做无用功且损耗效率
Secondary NameNode的职责分担NameNode的压力，按一定规则合并NameNode的edits到fsimage文件中。并且合并过程不影响NameNode的操作

合并规则

定时时间到了，请求获取相关文件，然后进行合并
edits文件的"数据满了"，例如，达到一定的操作次数

问题一：启动读取edits文件的过程
当NameNode启动的时候，edits_inprogress文件会将文件中的信息刷到一个edits文件中（文件结尾为事务开始id-事务结束id,表示刷进去的事务操作范围），并生成一个最新的edits_inprogress开头的文件，文件结尾为最新的事务id。NameNode拿到这个edits文件以后，与最新的fsimage镜像文件进行合并，生成新的fsimage并存储到磁盘上。

问题二：启动时读取edits+fsimage文件，而不是只读取fsimage
磁盘中的fsimage是由secondary namenode定期合并生成的最新的镜像文件，但是secondary namenode将操作日志合并到fsimage中是有周期性，在周期内，如果集群停掉，最新的日志文件就没有合并到fsimage中。
在这里插入图片描述

第一阶段：NameNode启动
①　在NameNode上通过bin/hdfs namenode -format命令格式化后，会在NameNode节点创建fsimage文件。通过sbin/start-dfs.sh第一次启动文件系统的时候，系统会把fsimage读取到内存中，而DataNode节点数据的相关变动，则保留在一系列的edits文件中，在下次（非第一次）文件系统重新启动的时候，先刷新edits_inprogress文件内容到edits文件，开启一个新的edits_inprogress文件记录后续操作，把目前的fsimage和所有的edits进行合并重新生成一个新的fsimage。
②　客户端发出对数据增删改的请求。
③　NameNode记录操作日志，更新滚动日志。
④　NameNode修改内存元数据。
注意：客户端的操作首先是写入到edits文件中，然后再操作内存中的数据

Namenode启动成功后，启动datanode
(1) datanode向namenode注册；
(2) datanode向namenode发送blockreport。
(3) datanode启动成功后，client可以对HDFS进行目录创建、文件上传、下载、查看、重命名等操作，更改namespace的操作将被记录在edit log文件中。

第二阶段：Secondary NameNode工作
①　Secondary NameNode请求执行CheckPoint操作。
②　Secondary NameNode通知NameNode准备提交edits文件，假设此时的编辑日志文件是edits_inprogress_001，所有的客户端的操作首先追加到该日志中，当NameNode提交edits日志文件的时候该日志名称为edits_001-005，并将它提交给Secondary NameNode，滚动产生edits_inprogress_006，新的操作信息存到新的日志文件中。
③　SecondaryNameNode通过http get方式获取NameNode的fsimage与edits文件
④　在SNN内存中对编辑日志和镜像文件进行合并。
⑤　生成新的镜像文件fsimage.chkpoint
⑥　拷贝fsimage.chkpoint到NameNode。
⑦　NameNode将fsimage.chkpoint重新命名成 fsimage_txid 的形式，后面txid表示此fsimage文件记录的已合并的最新操作的txid。

磁盘上的元数据文件
记录在edit Log文件中的每个操作都是一个独立的事务，每个事务有相应的操作码，唯一的事务ID以及操作对应的数据信息等。事务ID是由NameNode统一管理的，采用递增的方式，为每个操作赋予唯一的事务ID。最后一次操作的事务ID还会被写入到文件（seen_txid），namenode重启后会读取这些信息，并在最后一次事务ID上继续递增。

每个edit Log文件的文件名都有固定的格式，其中当前正在写的文件名格式为edits_inprogress_TXID，TXID为该文件中记录的第一个操作的事务ID；已经写完成的edit log文件名为 edts_StartTXID_EndTXID，StartTXID为该文件中记录的第一个操作的事务ID，EndTXID为该文件中记录的最后一个操作的事务ID，如下所示
在这里插入图片描述

说明：上图存在两个版本的fsimage分别为后缀318和320，318为上一次合并的fsimage文件，320表示当前的fsimage文件，当前日志是edits_inprogress_0000000000000000321，seen_txid记录着最新的编辑日志文件编号321
在这里插入图片描述

每次NameNode启动的时候都会将fsimage文件读入内存，从seen_txid文件中找到应该执行的Edits文件里的编号，执行所有Edits文件名末尾数字比seen_txid文件数字大的文件。如果seen_txid文件存储的是528，那么就意味着。重新启动NameNode时，NameNode会自动执行 edits_0000000000000000528文件及其之后的文件：如edits_0000000000000000529、edits_0000000000000000530等，直到最后一个，假设最后一个是531。然后生成一个edits_inprogress_0000000000000000532文件，用于记录启动之后的操作，然后，seen_txid文件里的数字就会变成532。

edits.new：又称edits_inprogress，正在写入的edits文件，用于存储最新的操作日志。每次checkponit，fsimage更新完成之后，重命名edits文件。

5.4.Fsimage和Edits解析

5.4.1.基本概念

如果每次对 HDFS 的操作都实时的把内存中的元数据信息往磁盘上传输，这样显然效率不够高，也不稳定，这时就出现了 Edits 文件，用来记录每次对 HDFS 的操作，这样在磁盘上每次就只用做很小改动（只进行追加操作），当 Edits 文件达到了一定大小或过了一定的时间，就需要把 Edits 文件转化 Fsimage 文件，然后重新生成一个edits_inprogress文件，这样的 Fsimage 文件不会和内存中的元数据实时同步，需要加上 Edits 文件才相等。
namenode被格式化之后，在NameNode服务器的dfs.namenode.name.dir目录中（一般为/data/dfs/name/current）产生如下文件

edits_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION

Fsimage文件：HDFS文件系统元数据的一个永久性检查点，其中包含HDFS文件系统的所有目录和文件inode的序列化信息。
Edits文件：编辑日志，存放着对HDFS文件系统的所有更新操作，文件系统客户端执行的所有增删改操作首先会被记录到edits文件中。
seen_txid文件保存的是一个数字，就是最后一个edits_inprogress的数字
每次NameNode启动的时候都会将fsimage文件读入内存，并执行所有Edits文件名末尾数字比seen_txid中记录的数字大的文件，保证内存中的元数据信息是最新的、同步的。

5.4.2.fsimage文件基本操作

查看oiv和oev命令

hdfs --help
Usage: hdfs [--config confdir] COMMAND
       where COMMAND is one of:
  dfs                  run a filesystem command on the file systems supported in Hadoop.
  namenode -format     format the DFS filesystem
  secondarynamenode    run the DFS secondary namenode
  namenode             run the DFS namenode
  journalnode          run the DFS journalnode
  zkfc                 run the ZK Failover Controller daemon
  datanode             run a DFS datanode
  dfsadmin             run a DFS admin client
  diskbalancer         Distributes data evenly among disks on a given node
  haadmin              run a DFS HA admin client
  fsck                 run a DFS filesystem checking utility
  balancer             run a cluster balancing utility
  jmxget               get JMX exported values from NameNode or DataNode.
  mover                run a utility to move block replicas across
                       storage types
  oiv                  apply the offline fsimage