namenode的fsimage与edits文件

最新推荐文章于 2023-04-28 17:31:14 发布
最新推荐文章于 2023-04-28 17:31:14 发布
阅读量575 收藏 2
点赞数 2
分类专栏： 大数据 # hadoop 文章标签： hadoop big data namenode fsimage edits
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43810802/article/details/120756933
版权

namenode的fsimage与edits文件

引入

hadoop集群中，namenode管理了元数据。那么，元数据存储在哪里呢？

如果是磁盘中，必然效率过低，如果是内存中，又会不安全。

所以元数据存储在内存中，但是有一个备份文件fsimage在磁盘。这就防止了断电元数据丢失的问题。

现在内存中的元数据增加之后，需要不断同步fsimage吗？这样又很没有效率。但你又必然要更新元数据，所以，可以将追加的操作写入一个文件edits。

fsimage与edits一起加载到内存中，就会得到所有的元数据。

合并

元数据一旦变得庞大，加载到内存就会很慢。所以，还需要定期去合并fsimage与edits。这个合并的工作最好由别人来做。

一般的集群中，可以由secondaryNameNode完成。

合并的时机可以是到一定的时间，或者是操作数到达一定阈值。

由于我使用的是hadoop3.1.3，所以我找了该版本的hdfs-default.xml:

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600s</value>
  <description>The number of seconds between two periodic checkpoints. 
Support multiple time unit suffix(case insensitive), as described in dfs.heartbeat.interval.</description>
</property>

<property>
  <name>dfs.namenode.checkpoint.txns</name>
  <value>1000000</value>
<description>The Secondary NameNode or CheckpointNode will create a checkpoint of the namespace every 'dfs.namenode.checkpoint.txns' transactions, 
regardless of whether 'dfs.namenode.checkpoint.period' has expired.</description>
</property>

<property>
  <name>dfs.namenode.checkpoint.check.period</name>
  <value>60s</value>
<description> The SecondaryNameNode and CheckpointNode will poll the NameNode every 'dfs.namenode.checkpoint.check.period' seconds to query the number of uncheckpointed transactions. 
Support multiple time unit suffix(case insensitive), as described in dfs.heartbeat.interval.</description>
</property>

默认的检查合并时间是一个小时，或者操作数到达了1000000。查询操作数的时间间隔为一分钟。

另一方面：

在这里插入图片描述
从我的hadoop元数据来看，有些edits的确是1个小时更新的，有些是因为启动关闭的时间不同造成混乱，但是没有一个edits超过1M，这是不是也是一个大小的限制呢？不得而知。如果默认是1M的话也太小了。

至于HA，那么我们就不需要secondaryNameNode来定期检查和合并了，做这份工作的是standBy namenode：

Note that, in an HA cluster, the Standby NameNodes also performs checkpoints of the namespace state, and thus it is not necessary to run a Secondary NameNode, CheckpointNode, or BackupNode in an HA cluster. In fact, to do so would be an error. This also allows one who is reconfiguring a non-HA-enabled HDFS cluster to be HA-enabled to reuse the hardware which they had previously dedicated to the Secondary NameNode.

查看

我将除了tmp文件之外的所有文件都删了：

在这里插入图片描述
最后我们观察几个文件：

在这里插入图片描述
首先，当前的最大操作数(事务数)为29325。

使用

hdfs oev -p XML -i edits_0000000000000029321-0000000000000029322 -o /opt/module/hadoop-3.1.3/edits.xml

得到edits_0000000000000029321-0000000000000029322的xml文件：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<EDITS>
  <EDITS_VERSION>-64</EDITS_VERSION>
  <RECORD>
    <OPCODE>OP_START_LOG_SEGMENT</OPCODE>
    <DATA>
      <TXID>29321</TXID>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_END_LOG_SEGMENT</OPCODE>
    <DATA>
      <TXID>29322</TXID>
    </DATA>
  </RECORD>
</EDITS>

这个操作就是开始和结束日志切分。

以同样的方式查看edits_inprogress_0000000000000029325：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<EDITS>
  <EDITS_VERSION>-64</EDITS_VERSION>
  <RECORD>
    <OPCODE>OP_START_LOG_SEGMENT</OPCODE>
    <DATA>
      <TXID>29325</TXID>
    </DATA>
  </RECORD>
</EDITS>

同样是日志切分的操作。它的TXID也是最大的操作数ID。secondaryNameNode唯独没有这个文件。可以说，它就是hadoop重启之后新增的操作。

我们可以通过

 hdfs oiv -p XML -i fsimage_0000000000000029324 -o /opt/module/hadoop-3.1.3/fsimage_new.xml

查看fsimage：

<INodeSection>
		<lastInodeId>22648</lastInodeId>
		<numInodes>27</numInodes>
		<inode>
			<id>16385</id>
			<type>DIRECTORY</type>
			<name/>
			<mtime>1629345954854</mtime>
			<permission>root:supergroup:0777</permission>
			<nsquota>9223372036854775807</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22554</id>
			<type>DIRECTORY</type>
			<name>tmp</name>
			<mtime>1629289108967</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22555</id>
			<type>DIRECTORY</type>
			<name>hadoop-yarn</name>
			<mtime>1629280562345</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22556</id>
			<type>DIRECTORY</type>
			<name>staging</name>
			<mtime>1629289107248</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22557</id>
			<type>DIRECTORY</type>
			<name>history</name>
			<mtime>1629280562367</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22558</id>
			<type>DIRECTORY</type>
			<name>done</name>
			<mtime>1629289269870</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22559</id>
			<type>DIRECTORY</type>
			<name>done_intermediate</name>
			<mtime>1629289110600</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22573</id>
			<type>DIRECTORY</type>
			<name>ocean</name>
			<mtime>1629289107248</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22574</id>
			<type>DIRECTORY</type>
			<name>.staging</name>
			<mtime>1629290164292</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22580</id>
			<type>DIRECTORY</type>
			<name>logs</name>
			<mtime>1629289108990</mtime>
			<permission>ocean:ocean:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22581</id>
			<type>DIRECTORY</type>
			<name>ocean</name>
			<mtime>1629289108992</mtime>
			<permission>ocean:ocean:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22582</id>
			<type>DIRECTORY</type>
			<name>logs-tfile</name>
			<mtime>1629290147310</mtime>
			<permission>ocean:ocean:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22583</id>
			<type>DIRECTORY</type>
			<name>application_1629280557686_0001</name>
			<mtime>1629289238916</mtime>
			<permission>ocean:ocean:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22584</id>
			<type>DIRECTORY</type>
			<name>ocean</name>
			<mtime>1629290169798</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22608</id>
			<type>FILE</type>
			<name>job_1629280557686_0001-1629289108111-ocean-hadoop%2Dmapreduce%2Dclient%2Djobclient%2D3.1.3%2D-1629289231294-10-1-SUCCEEDED-default-1629289112345.jhist</name>
			<replication>3</replication>
			<mtime>1629289231358</mtime>
			<atime>1629289231340</atime>
			<preferredBlockSize>134217728</preferredBlockSize>
			<permission>ocean:supergroup:0777</permission>
			<blocks>
				<block>
					<id>1073744990</id>
					<genstamp>4174</genstamp>
					<numBytes>55176</numBytes>
				</block>
			</blocks>
			<storagePolicyId>0</storagePolicyId>
		</inode>
		<inode>
			<id>22609</id>
			<type>FILE</type>
			<name>job_1629280557686_0001_conf.xml</name>
			<replication>3</replication>
			<mtime>1629289231386</mtime>
			<atime>1629289231366</atime>
			<preferredBlockSize>134217728</preferredBlockSize>
			<permission>ocean:supergroup:0777</permission>
			<blocks>
				<block>
					<id>1073744991</id>
					<genstamp>4175</genstamp>
					<numBytes>216419</numBytes>
				</block>
			</blocks>
			<storagePolicyId>0</storagePolicyId>
		</inode>
		<inode>
			<id>22610</id>
			<type>FILE</type>
			<name>hadoop102_35246</name>
			<replication>3</replication>
			<mtime>1629289238515</mtime>
			<atime>1629289238458</atime>
			<preferredBlockSize>134217728</preferredBlockSize>
			<permission>ocean:ocean:0777</permission>
			<blocks>
				<block>
					<id>1073744992</id>
					<genstamp>4176</genstamp>
					<numBytes>172209</numBytes>
				</block>
			</blocks>
			<storagePolicyId>0</storagePolicyId>
		</inode>
		<inode>
			<id>22611</id>
			<type>FILE</type>
			<name>hadoop103_33694</name>
			<replication>3</replication>
			<mtime>1629289238912</mtime>
			<atime>1629289238844</atime>
			<preferredBlockSize>134217728</preferredBlockSize>
			<permission>ocean:ocean:0777</permission>
			<blocks>
				<block>
					<id>1073744993</id>
					<genstamp>4177</genstamp>
					<numBytes>352999</numBytes>
				</block>
			</blocks>
			<storagePolicyId>0</storagePolicyId>
		</inode>
		<inode>
			<id>22612</id>
			<type>DIRECTORY</type>
			<name>2021</name>
			<mtime>1629289269870</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22613</id>
			<type>DIRECTORY</type>
			<name>08</name>
			<mtime>1629289269870</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22614</id>
			<type>DIRECTORY</type>
			<name>18</name>
			<mtime>1629289269870</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22615</id>
			<type>DIRECTORY</type>
			<name>000000</name>
			<mtime>1629290169798</mtime>
			<permission>ocean:supergroup:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22632</id>
			<type>DIRECTORY</type>
			<name>application_1629280557686_0002</name>
			<mtime>1629290170700</mtime>
			<permission>ocean:ocean:0777</permission>
			<nsquota>-1</nsquota>
			<dsquota>-1</dsquota>
		</inode>
		<inode>
			<id>22645</id>
			<type>FILE</type>
			<name>job_1629280557686_0002-1629290147211-ocean-hadoop%2Dmapreduce%2Dclient%2Djobclient%2D3.1.3%2D-1629290163180-10-1-SUCCEEDED-default-1629290150116.jhist</name>
			<replication>3</replication>
			<mtime>1629290163238</mtime>
			<atime>1629290163222</atime>
			<preferredBlockSize>134217728</preferredBlockSize>
			<permission>ocean:supergroup:0777</permission>
			<blocks>
				<block>
					<id>1073745012</id>
					<genstamp>4196</genstamp>
					<numBytes>54938</numBytes>
				</block>
			</blocks>
			<storagePolicyId>0</storagePolicyId>
		</inode>
		<inode>
			<id>22646</id>
			<type>FILE</type>
			<name>job_1629280557686_0002_conf.xml</name>
			<replication>3</replication>
			<mtime>1629290163262</mtime>
			<atime>1629290163244</atime>
			<preferredBlockSize>134217728</preferredBlockSize>
			<permission>ocean:supergroup:0777</permission>
			<blocks>
				<block>
					<id>1073745013</id>
					<genstamp>4197</genstamp>
					<numBytes>216417</numBytes>
				</block>
			</blocks>
			<storagePolicyId>0</storagePolicyId>
		</inode>
		<inode>
			<id>22647</id>
			<type>FILE</type>
			<name>hadoop103_33694</name>
			<replication>3</replication>
			<mtime>1629290170343</mtime>
			<atime>1629290170309</atime>
			<preferredBlockSize>134217728</preferredBlockSize>
			<permission>ocean:ocean:0777</permission>
			<blocks>
				<block>
					<id>1073745014</id>
					<genstamp>4198</genstamp>
					<numBytes>203114</numBytes>
				</block>
			</blocks>
			<storagePolicyId>0</storagePolicyId>
		</inode>
		<inode>
			<id>22648</id>
			<type>FILE</type>
			<name>hadoop102_35246</name>
			<replication>3</replication>
			<mtime>1629290170698</mtime>
			<atime>1629290170675</atime>
			<preferredBlockSize>134217728</preferredBlockSize>
			<permission>ocean:ocean:0777</permission>
			<blocks>
				<block>
					<id>1073745015</id>
					<genstamp>4199</genstamp>
					<numBytes>281375</numBytes>
				</block>
			</blocks>
			<storagePolicyId>0</storagePolicyId>
		</inode>
	</INodeSection>

除了核心文件，已经没有自己建文件或文件夹了。

同样的我们可以查看另个一个fsimage。

注意到两个对应的数字（在我写博文的途中又发生了合并，所以数字与前面的截图不同了）：

在这里插入图片描述

这相当于是存了最后的两个版本。那为什么会有两个fsimage呢？

<property>
  <name>dfs.namenode.num.checkpoints.retained</name>
  <value>2</value>
<description> The number of image checkpoint files (fsimage_*) that will be retained by the NameNode and Secondary NameNode in their storage directories. 
All edit logs (stored on edits_* files) necessary to recover an up-to-date namespace from the oldest retained checkpoint will also be retained.</description>
</property>

默认就是2。

spark man
关注
专栏目录
大数据之-Hadoop之HDFS_Fsimage和Edits文件的解析---大数据之hadoop工作笔记0071
添柴程序猿的专栏
04-06 443
我们知道fsimage文件是,hadoop的hdfs,在写入文件的时候,为了保险把数据固化的磁盘的上的这个文件叫做fsimage 而edits文件,是为了数据传输的比较快,会先把数据的操作记录,记录到这个edits文件中,然后适时再去把edits文件中的内容, 同步到fsimage磁盘上. ..
大数据之-Hadoop之HDFS_合并FsImage和Edits文件_之CheckPoint时间设置---大数据之hadoop工作笔记0072
添柴程序猿的专栏
04-07 418
我们说,secondarynamenode会定时的,或者说等edits文件满了以后就会把, namenode节点的fsimage文件以及edits文件滚动出来一版,然后copy到secondarynamenode节点上, 然后把这两个文件合并起来,形成一个新的fsimage文件,持久化到磁盘上. 那么这个定时,是怎么定时呢? 可以看到上面是说secondarynamenode,会进行检查edits文件有没有满,什么时候检查是,根据,1.定时时间到 2.edits文件中的操作记录数据满了以.
hadoop查看namenode edits文件
weixin_38610500的博客
10-27 356
NameNode上的fsimage和edits文件
obcy
12-23 920
思考：NameNode中的元数据是存储在哪里的？ 首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。 这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效...
NameNode中的Fsimage和Edits解析
叁木大数据
12-25 3299
NameNode中的Fsimage和Edits解析图解name 图解name
怎么理解namenode中的fsimage和edits文件
qq_28069577的博客
06-06 971
怎么理解这两个文件？ 这两个文件本质上是一样，都是备份。 先从盘古开天地讲起，（给你设计你会怎么设计） 一开始，光有namenode进程，还并没有这两个文件的概念，当外部客户端有操作了，namenode进程把客户端的操作生成元数据，在进程中记录下来，也就是可能在内存维护一个列表数据结构之类的什么吧。 就这样吧，能用了 问题是这样直接记录在内存中，一掉电这些信息就丢了（服务器不重启就还能好...
【Hadoop-HDFS】HDFS中Fsimage与Edits详解
最新发布
weixin_53543905的博客
04-28 2416
在HDFS中，NameNode 保存了整个 HDFS 的元数据信息，而这些数据最终会被持久化到 Fsimage 文件和 EditLog 文件。换而言之，NameNode 的元数据信息由Fsimage和Editlog组成。Fsimage 存放上次 checkpoint 生成的文件系统元数据。EditLog 则存放文件系统的操作日志，也就是用户对目录、文件的每个写操作（包括创建、删除、写入等）都会被记录到 Editlog 文件中。注意。【Hadoop-HDFS】HDFS中Fsimage与Edits详解
HDFS NameNode fsimage文件corrupt了，怎么办
走在前往架构师的路上
12-19 2036
文章目录前言NameNode fsimage corrupt场景NameNode fsimage corrupt解决办法NN fsimage corrupt的重新行为参考链接 前言 在如今很多用户使用HDFS做为大数据的底层存储时，我们除了关心HDFS的处理性能外，我们经常还需要关注其中数据高可用的情况，例如不能出现数据损坏的情况，比如missing block，或者文件block corrupt的情况。但是其中我们忽略掉了一种最为极端同时也是最为棘手的情况：HDFS NameNode fsimage文件
NameNode工作机制中FsImage与edits
LemonTreeWN的博客
06-24 439
1. Fsimage中没有记录块所对应DataNode，为什么？ 答。在集群启动后，要求DataNode上报数据块信息，并间隔一段时间后再次上报。 在fsimage中，并没有记录每一个block对应到哪几个datanodes的对应表信息，而只是存储了所有的关于namespace的相关信息。而真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储，而是在所有datanode启动时，每个datanode对本地磁盘进行扫描，将本datanode上保存的block信息汇报给na
fsimage和edits详解
Hxm6440的博客
11-08 745
namenode元数据解析 第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载edits和fsimage文件到内存 客户端对元数据进行增删改的请求 namenode记录操作日志，更新滚动日志 namenode在内存中对数据进行增删改查 fsimage保存了最新的元数据检查点，在HDFS启动时加载fsimage的信息，包含了整个HDFS文件系...
hadoop中fsimage和edits的区别
古韦的专栏
10-15 3266
1、概念： fsimage保存了最新的元数据检查点。 edits保存自最新检查点后的命名空间的变化。 2、工作原理： 从最新检查点后，hadoop将对每个文件的操作都保存在edits中，为避免edits不断增大，secondary namenode就会周期性合并fsimage和edits成新的fsimage，edits再记录新的变化。 这种机制有个问题：因edits存放在Name
HDFS中NameNode的fsimage和edits
lucyLee的博客
07-26 1488
① NameNode元数据的设计 在HDFS中，需要经常访问元数据，并且还要求NameNode能高效地响应Client的请求。如果将元数据存储在NameNode的磁盘中，必然效率太低。 应该将元数据存到内存中。 但是，元数据如果存储在内存中，一旦断电，就会丢失。重启后，整个集群便无法工作。 应该在磁盘中对元数据进行备份，叫做fsimage。 内存中的元数据发生更新，磁盘中的fsimage也需要同时更新，才能保证数据的一致性。但是，如果内存中的元数据每更新一次，就同步到磁盘，效率会非常低下。
NameNode节点加载FSImage+EditsLog
xhh198781的专栏
11-21 3614
在前面的博文中，我曾多次提到过在NameNode的启动过程中有加载FSImage+EditsLog这一必不可少的一项。关于文件fsImage和文件edits是用来存放神马的，我在这里就不用在重复了吧。在本文我将详细的叙述NameNode是如何加载fsimage和edits文件的。       在NameNode节点启动之前，我们一般会在配置文件hdfs-default.xml中分别配置文件fsI
关于面试--【namenode&fsimage&edits】
hxiaowang的博客
08-15 518
namenode和镜像文件之间的一些过程和考点
namenode的fsimage与editlog详解
lzf的博客
05-10 3485
Namenode主要维护两个文件，一个是fsimage，一个是editlog。 fsimage保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信息、修改时间、访问时间等；对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。 editlog主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录，HDFS...
hadoop_hdfs namenode故障恢复（namenode中fsimage与edits文件损坏）
qq_45798620的博客
10-14 2624
NameNode故障恢复原理流程namenode保存fsimage的配置路径namenode保存edits文件的配置路径secondaryNamenode保存fsimage文件的配置路径secondaryNamenode保存edits文件的配置路径故障恢复代码解决方案 原理 使用为什么使用故障恢复的原理 流程 secondaryNamenode对namenode当中的fsimage和edits进行合并时，每次都会先将namenode的fsimage与edits文件拷贝一份过来，所以fsimage与edit
HDFS editlog和fsimage文件
qq_41982570的博客
03-05 913
HDFS editlog和fsimage文件
HDFS : Fsimage与Edits 详解
热门推荐
11-07 1万+
Fsimage Edits详解 NameNode元数据解析 （1）第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载edits和fsimage文件到内存。 （2）客户端对元数据进行增删改的请求。 （3）namenode记录操作日志，更新滚动日志。 （4）namenode在内存中对数据进行增删改查。 Fsimage保存了最新的元数据检查点，在H...
Linux应用编程（2）lseek/dup/dup2函数介绍
weixin_44112805的博客
09-08 521
lseek函数 1.lseek函数介绍 /* *@pram: fd :文件描述符 * offset :偏移量 * whence :偏移开始的位置 (SEEK_SET / SEEK_CUR / SEEK_END) *@return value :offset到文件末尾的字节数 */ off_t lseek(int fd, off_t offset, int whence); 文件指针：当我们要对一个文件进行读写时，一定需要先打开这个文件，所以我们读写的所有文件都是
HDFS NameNode与SecondaryNameNode工作机制详解
随着时间推移，edits文件会不断增长，为确保NameNode的高效运行，需要定期将内存中的数据与edits文件合并成新的fsimage。 SecondaryNameNode（2NN）并非NameNode的热备，它的主要任务是帮助NameNode定期进行检查点...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值