五、NameNode和SecondaryNameNode的介绍

最新推荐文章于 2024-06-10 05:30:00 发布
最新推荐文章于 2024-06-10 05:30:00 发布
阅读量423 收藏
点赞数
分类专栏： hadoop
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_35241080/article/details/105960801
版权

一、NN和SNN工作机制

         了解hadoop的一定不会陌生NameNode和SecondaryNameNode这两个组件，NameNode是保存数据元信息，SecondaryNameNode是帮助NN工作，也可以做元数据备份工作。

在这里插入图片描述


1.第一阶段：NameNode启动
（1）第一次启动NameNode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求。
（3）NameNode记录操作日志，更新滚动日志。
（4）NameNode在内存中对数据进行增删改查。


2.第二阶段：Secondary NameNode工作
（1）Secondary NameNode询问NameNode是否需要checkpoint。直接带回NameNode是否检查结果。
（2）Secondary NameNode请求执行checkpoint。
（3）NameNode滚动正在写的edits日志，将后续操作写入新的edits日志文件
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint。
（7）拷贝fsimage.chkpoint到NameNode。
（8）NameNode将fsimage.chkpoint重新命名成fsimage。
（9）此时fsimage与滚动后的edits编辑日志就是最新元数据


3. NN和2NN工作机制详解：

Fsimage：NameNode内存中元数据序列化后形成的文件。

Edits：记录客户端更新元数据信息的每一步操作（可通过Edits运算出元数据）。


3.1 集群启动时做了哪些工作？

1.NameNode启动工作：启动合并数据

       NameNode启动时，先滚动Edits并生成一个空的edits.inprogress，然后加载Edits和Fsimage到内存中，此时NameNode内存就持有最新的元数据信息。


2.客户端对文件操作记录：编辑日志

       Client开始对NameNode发送元数据的增删改的请求，这些请求的操作首先会被记录到edits.inprogress中（查询元数据的操作不会被记录在Edits中，因为查询操作不会更改元数据信息），如果此时NameNode挂掉，重启后会从Edits中读取元数据的信息。然后，NameNode会在内存中执行元数据的增删改的操作。


3.随着操作记录越来越多Edits文件过大，会导致NameNode启动缓慢

       由于Edits中记录的操作会越来越多，Edits文件会越来越大，导致NameNode在启动加载Edits时会很慢，所以需要对Edits和Fsimage进行合并（所谓合并，就是将Edits和Fsimage加载到内存中，照着Edits中的操作一步步执行，最终形成新的Fsimage）。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。


4.SecondaryNameNode触发执行元数据备份流程

       1. SecondaryNameNode首先会询问NameNode是否需要CheckPoint（触发CheckPoint需要满足两个条件中的任意一个，定时时间到和Edits中数据写满了-文件操作次数）。直接带回NameNode是否检查结果。
       2. SecondaryNameNode执行CheckPoint操作，首先会让NameNode滚动Edits并生成一个空的edits.inprogress，滚动Edits的目的是给Edits打个标记，以后所有新的操作都写入edits.inprogress，其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地。
       3. 然后将拷贝的Edits和Fsimage加载到内存中进行合并，生成fsimage.chkpoint。
       4. 然后将fsimage.chkpoint拷贝给NameNode，重命名为Fsimage后替换掉原来的Fsimage
       5.NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可，因为合并过的Edits中的元数据信息已经被记录在Fsimage中。

注意：每次SecondaryNameNode合并一次数据将生成一个新的edits操作文件。









二、Fsimage和Edits解析

1、NameNode下数据文件介绍
       集群搭建完毕启动前需要先格式化NameNode，NameNode被格式化后，会在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current 目录下生成文件：seen_txid、VERSION、fsimage、edits

       1.1 fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件inode的序列化信息
       1.2 edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到Edits文件中。
       1.3 seen_txid：保存的是最后一个edits_ 的数字
       1.4 每次 NameNode 启动的时候会将fsimage文件读入内存，加载edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动时将fsimage与edits文件进行了合并


2、使用oiv查看Fsimage文件

操作如下：

（1）查看oiv和oev命令介绍
[root@hadoop102 current]$ hdfs
oiv            apply the offline fsimage viewer to an fsimage
oev            apply the offline edits viewer to an edits file

（2）基本语法
hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径

（3）案例实操
[root@hadoop102 current]$ pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current
[root@hadoop102 current]$ hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-2.7.2/fsimage.xml
[root@hadoop102 current]$ cat /opt/module/hadoop-2.7.2/fsimage.xml

查看生成的fsimage.xml文件部分数据

在这里插入图片描述

文件信息：
<inode>
    <id>21058</id>
    <type>FILE</type> 类型
    <name>2.txt</name> 文件名
    <replication>3</replication> 备份数量
    <mtime>1588771338974</mtime> 最后操作时间1588771338，去掉后三位转换格式
    <atime>1588771338686</atime>
    <perferredBlockSize>134217728</perferredBlockSize> 剩余的块存储空间
    <permission>root:supergroup:rw-r--r--</permission>权限
    <blocks>
        <block>
            <id>1073744178</id>
            <genstamp>3354</genstamp>
            <numBytes>271</numBytes> 文件大小
        </block>
    </blocks>
</inode>

数据块大小：(134217728+271)/1024/1024=128

目录信息：

<inode>
    <id>21055</id> 
    <type>DIRECTORY</type> 类型
    <name>test2</name>目录名
    <mtime>1588771338686</mtime>最后修改时间
    <permission>root:supergroup:rwxr-xr-x</permission>权限
    <nsquota>-1</nsquota>
    <dsquota>-1</dsquota>
</inode>

3、 oev查看Edits文件

（1）基本语法
hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
（2）案例实操
[root@hadoop102 current]$ hdfs oev -p XML -i edits_inprogress_0000000000000055469 -o /opt/module/hadoop-2.7.2/edits.xml
[root@hadoop102 current]$ cat /opt/module/hadoop-2.7.2/edits.xml

（3）将显示的xml文件内容拷贝到Eclipse中创建的xml文件中，并格式化。显示结果如下。

xml部分文件信息解读：
执行了三步操作：
1.创建文件夹test
2.上传本地hb.txt文件至hdfs
3.删除hdfs中hb.txt文件

<?xml version="1.0" encoding="UTF-8"?>
<EDITS>
  <EDITS_VERSION>-63</EDITS_VERSION> 版本
  <RECORD>
    <OPCODE>OP_START_LOG_SEGMENT</OPCODE>
    <DATA>
      <TXID>55469</TXID>
    </DATA>
  </RECORD>

  <RECORD>
    <OPCODE>OP_MKDIR</OPCODE>  第一步创建文件夹
    <DATA>
      <TXID>55470</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>31585</INODEID>
      <PATH>/test</PATH>
      <TIMESTAMP>1588771220227</TIMESTAMP>
      <PERMISSION_STATUS>
        <USERNAME>root</USERNAME> 创建用户
        <GROUPNAME>supergroup</GROUPNAME>
        <MODE>493</MODE>
      </PERMISSION_STATUS>
    </DATA>
  </RECORD>

  <RECORD>
    <OPCODE>OP_ADD</OPCODE>  第二步上传文件
    <DATA>
      <TXID>55471</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>31586</INODEID>
      <PATH>/test/hb.txt._COPYING_</PATH> 文件地址
      <REPLICATION>3</REPLICATION>
      <MTIME>1588771259904</MTIME>
      <ATIME>1588771259904</ATIME>	操作时间
      <BLOCKSIZE>134217728</BLOCKSIZE> 数据块大小 128MB
      <CLIENT_NAME>DFSClient_NONMAPREDUCE_1441890911_1</CLIENT_NAME>
      <CLIENT_MACHINE>192.168.56.102</CLIENT_MACHINE> 客户端ip
      <OVERWRITE>true</OVERWRITE>
      <PERMISSION_STATUS>
        <USERNAME>root</USERNAME>
        <GROUPNAME>supergroup</GROUPNAME>
        <MODE>420</MODE>
      </PERMISSION_STATUS>
      <RPC_CLIENTID>09a6342a-82f4-4355-8b37-9e8f59252473</RPC_CLIENTID>
      <RPC_CALLID>3</RPC_CALLID>
    </DATA>
  </RECORD>

  <RECORD>
    <OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
    <DATA>
      <TXID>55472</TXID>
      <BLOCK_ID>1073744931</BLOCK_ID>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_SET_GENSTAMP_V2</OPCODE>
    <DATA>
      <TXID>55473</TXID>
      <GENSTAMPV2>4159</GENSTAMPV2>
    </DATA>
  </RECORD>

  <RECORD>
    <OPCODE>OP_ADD_BLOCK</OPCODE>
    <DATA>
      <TXID>55474</TXID>
      <PATH>/test/hb.txt._COPYING_</PATH>
      <BLOCK>
        <BLOCK_ID>1073744931</BLOCK_ID>
        <NUM_BYTES>0</NUM_BYTES>
        <GENSTAMP>4159</GENSTAMP>
      </BLOCK>
      <RPC_CLIENTID></RPC_CLIENTID>
      <RPC_CALLID>-2</RPC_CALLID>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_CLOSE</OPCODE>
    <DATA>
      <TXID>55475</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>0</INODEID>
      <PATH>/test/hb.txt._COPYING_</PATH>
      <REPLICATION>3</REPLICATION>
      <MTIME>1588771260459</MTIME>
      <ATIME>1588771259904</ATIME>
      <BLOCKSIZE>134217728</BLOCKSIZE>
      <CLIENT_NAME></CLIENT_NAME>
      <CLIENT_MACHINE></CLIENT_MACHINE>
      <OVERWRITE>false</OVERWRITE>
      <BLOCK>
        <BLOCK_ID>1073744931</BLOCK_ID>
        <NUM_BYTES>75</NUM_BYTES>
        <GENSTAMP>4159</GENSTAMP>
      </BLOCK>
      <PERMISSION_STATUS>
        <USERNAME>root</USERNAME>
        <GROUPNAME>supergroup</GROUPNAME>
        <MODE>420</MODE>
      </PERMISSION_STATUS>
    </DATA>
  </RECORD>

  <RECORD>
    <OPCODE>OP_RENAME_OLD</OPCODE>
    <DATA>
      <TXID>55476</TXID>
      <LENGTH>0</LENGTH>
      <SRC>/test/hb.txt._COPYING_</SRC>
      <DST>/test/hb.txt</DST>
      <TIMESTAMP>1588771260477</TIMESTAMP>
      <RPC_CLIENTID>09a6342a-82f4-4355-8b37-9e8f59252473</RPC_CLIENTID>
      <RPC_CALLID>8</RPC_CALLID>
    </DATA>
  </RECORD>


  <RECORD>
    <OPCODE>OP_DELETE</OPCODE>		第三步文件删除操作
    <DATA>
      <TXID>55483</TXID>
      <LENGTH>0</LENGTH>
      <PATH>/test/hb.txt</PATH>
      <TIMESTAMP>1588771323014</TIMESTAMP>
      <RPC_CLIENTID>4d68339f-75b2-46d9-9dc9-28dd59210124</RPC_CLIENTID>
      <RPC_CALLID>3</RPC_CALLID>
    </DATA>
  </RECORD>
</EDITS>

三、 CheckPoint时间设置

hdfs-default.xml：文件参数设置

（1）通常情况下，SecondaryNameNode每隔一小时执行一次。

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>
</property>

（2）一分钟检查一次操作次数，3当操作次数达到1百万时，SecondaryNameNode执行一次。

<property>
  <name>dfs.namenode.checkpoint.txns</name>
  <value>1000000</value>
<description>操作动作次数</description>
</property>

<property>
  <name>dfs.namenode.checkpoint.check.period</name>
  <value>60</value>
<description> 1分钟检查一次操作次数</description>
</property >
风zi
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
第5章 NameNode和SecondaryNameNode
留不住斜阳的博客
06-02 1033
NameNode和SecondaryNameNode工作机制详解
NameNode和SecondaryNameNode
weixin_45102492的博客
02-19 148
NN和2NN工作机制 NameNode中的元数据是存储在哪里的？ 首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。 这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage...
浅析 Secondary NameNode(辅助namenode)
会飞的大象
05-03 1万+
浅析 Secondary NameNode(辅助namenode)
NameNode 和 SecondaryNameNode
最新发布
程序猿进阶
06-10 1100
由于 Edits中记录的操作会越来越多，Edits文件会越来越大，导致 NameNode在启动加载 Edits时会很慢，所以需要对 Edits和Fsimage进行合并（所谓合并，就是将 Edits和 Fsimage加载到内存中，照着 Edits中的操作一步步执行，最终形成新的Fsimage）。这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦 NameNode节点断电，就会产生数据丢失。因此，元数据需要存放在内存中。
NameNode和SecondaryNameNode详解
热门推荐
安歌Object
08-14 1万+
一、NN和2NN工作机制 NN和2NN工作机制，如图 1.第一阶段：NameNode启动 （1）第一次启动NameNode格式化后，创建fsimage和edits文件。 如果不是第一次启动，直接加载编辑日志和镜像文件到内存。 （2）客户端对元数据进行增删改的请求。 （3）NameNode记录操作日志，更新滚动日志。 （4）NameNode在内存中对数据进行增删改查。 2....
secondary namenode 检查点
dingqiu6346的博客
09-14 742
secondary namenode NameNode职责是管理元数据信息，DataNode的职责是负责数据具体存储，那么SecondaryNameNode的作用是什么？对很多初学者来说是非常迷惑的。它为什么会出现在HDFS中。从它的名字上看，它给人的感觉就像是NameNode的备份。但它实际上却不是。 大家猜想一下，当HDFS集群运行一段事件后，就会出现下面一些问题：...
Secondary Namenode
LaZY的博客
06-16 141
Namenode的元数据 (目录中的文件) VERSION文件:包含运行hdfs的版本信息，其中重要属性blockpoolID：记录了一个Namenode管理的命名空间中的所有文件。 编辑日志：客户端执行写操作，这些事务会记录到其中。 映像文件（Fsimage）：包含整个文件系统所有的文件和目录，文件系统元数据的完整永久性检查点。 Namenode和Secondary Namenode 由于在Na...
快速学习-NameNode和SecondaryNameNode
01-07
第5章 NameNode和SecondaryNameNode（面试开发重点） 5.1 NN和2NN工作机制 思考：NameNode中的元数据是存储在哪里的？ 首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应...
Hadoop中namenode和secondarynamenode工作机制讲解
09-30
在HDFS中，namenode和secondarynamenode起着至关重要的作用，它们确保了HDFS元数据的完整性和可靠性。 namenode是HDFS的主服务器，负责管理文件系统命名空间，维护文件系统树及整个HDFS的目录结构。所有关于文件...
HDFS中NameNode和SecondaryNameNode工作机制详解
a1786742005的博客
02-03 2458
一、为何要引入SecondaryName？ 思考：NameNode中的元数据是储存在哪里的？        首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生...
NameNode及SecondaryNameNode分析
07-07
NameNode及SecondaryNameNode分析
11_尚硅谷大数据之HDFS_NameNode和SecondaryNameNode1
08-03
下面我们将详细探讨NameNode和SecondaryNameNode的工作机制，以及Fsimage和Edits文件的作用。 1. NameNode工作流程： - **首次启动**：NameNode会格式化存储，生成初始的Fsimage和Edits文件。之后，每次启动时，...
Secondary NameNode
he515的博客
06-11 209
Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点 NN掌握一批元数据 为了保证元数据的安全，将内存中的数据存放在磁盘中 持久化： 当我们的集群因断电等待特殊原因产生问题的时候，问题解决，重新开机，会去磁盘上读取元数据，恢复到断电前的状态 NN不能进行持久化的 原因： 其实他可以做因为需求小，占用内存少，不影响计算效率 不可以做的原因是...
secondarynamenode
qq_40693443的博客
05-31 380
1.3.4 SecondaryNameNode 存在的意义 edits log会随着对文件系统的操作而无限制地增长，这对正在运行的NameNode而言没有任何影响，如果NameNode重启，则需要很长的时间执行edits log的记录以更新fsimage（元数据镜像文件）。在此期间，整个系统不可用。 在系统启动期间，NameNode合并fsimage+edits log fsimage=0 edist log=很大 内存 fsimage=GB edits log 内存->执行edits log条目 解
2021-04-17
Zerorhero的博客
04-17 208
数据来源：拉钩教育大数据高薪开发训练营 Hadoop学习第六部分：NameNode与SecondaryNameNode 1）HDFS元数据管理机制 问题1：NameNode如何管理和存储元数据？ 计算机中存储数据两种：内存或者是磁盘 元数据存储磁盘：存储磁盘无法面对客户端对元数据信息的任意的快速低延迟的响应，但是安全性高； 元数据存储内存：元数据存放内存，可以高效的查询以及快速响应客户端的查询请求，数据保存在内存，如果断点，内存中的数据全部丢失。 解决方案：内存+磁盘；NameNode内存+FsImage的
六、HDFS中的NameNode和SecondaryNameNode
象在舞的技术专栏
07-26 3184
上篇博客介绍了Hadoop的核心组件HDFS，本篇主要介绍HDFS中的NameNode和SecondaryNameNode，关注专栏《from zero to hero（Hadoop篇）》查看相关系列的文章~ 在这之前，我们首先得弄明白一件事情：NameNode中的元数据是存储在哪里的？我们可以假设一下，如果元数据存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还要响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失...
SecondaryNameNode讲解
依旧的博客
11-06 6234
简介 HA的一个解决方案。但不支持热备。配置即可。 执行过程：从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，替换旧的fsimage. 默认在安装在NameNode节点上，但这样...不安全！ 一、secondarynameNode工作原理 使用原因： 未使用secondar...
namenode和secondarynamenode
03-16
Namenode 和 Secondarynamenode 是 Hadoop 中的两个重要组件。Namenode 是整个 Hadoop 集群的管理中心，负责维护文件系统的元数据，如文件目录结构、文件权限等。Secondarynamenode 则负责与 Namenode 配合工作，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值