首页 > 其他分享> > Hdfs Editslog FsImage SecondaryNN与NN工作机制

Hdfs Editslog FsImage SecondaryNN与NN工作机制

2021-01-26 21:57:24 作者：互联网

文章目录

Hdfs Editslog FsImage SecondaryNN与NN工作机制

Hdfs Editslog FsImage SecondaryNN与NN工作机制

【文件(目录)元数据】存储在【NameNode内存】中,使用arrayList。

1.FsImage

为了防止NN断电，内存元数据信息丢失，将元数据信息保存在磁盘FsImage文件中。

FsImage文件不是在元数据写入内存时，同时写入FsImage文件；而是通过Secondary NN合并时，生成新的FsImage文件。

FsImage文件内容

//FsImage部分数据
<inode>
	<id>16386</id>
	<type>DIRECTORY</type>
	<name>user</name>
	<mtime>1512722284477</mtime>
	<permission>atguigu:supergroup:rwxr-xr-x</permission>
	<nsquota>-1</nsquota>
	<dsquota>-1</dsquota>
</inode>
<inode>
	<id>16387</id>
	<type>DIRECTORY</type>
	<name>atguigu</name>
	<mtime>1512790549080</mtime>
	<permission>atguigu:supergroup:rwxr-xr-x</permission>
	<nsquota>-1</nsquota>
	<dsquota>-1</dsquota>
</inode>
<inode>
	<id>16389</id>
	<type>FILE</type>
	<name>wc.input</name>
	<replication>3</replication>
	<mtime>1512722322219</mtime>
	<atime>1512722321610</atime>
	<perferredBlockSize>134217728</perferredBlockSize>
	<permission>atguigu:supergroup:rw-r--r--</permission>
	<blocks>
		<block>
			<id>1073741825</id>
			<genstamp>1001</genstamp>
			<numBytes>59</numBytes>
		</block>
	</blocks>
</inode >

思考：可以看出，Fsimage中没有记录块所对应DataNode，为什么？
每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储，
而是在datanode启动时，每个datanode对本地磁盘进行扫描，
将本datanode上保存的block信息汇报给namenode，namenode在接收到每个datanode的块信息汇报后，
将接收到的块信息，以及其所在的datanode信息等保存在内存中(BlocksMap)。
（HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanode向namenode汇报块信息的过程叫做blockReport，而namenode将block -> datanodes list的对应表信息保存在一个叫BlocksMap的数据结构中。）

2.Edits

记录客户端对hdfs的修改log。
当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。注意：写Edits首先写入内存缓冲区，当触发刷盘机制时，将内存中的Edits数据刷入Edits文件。
记录在edits文件中的每个操作都是一个独立的事务，每个事务有相应的操作码，唯一的事务ID以及操作对应的数据信息等。事务ID是由namenode统一管理的，采用递增的方式，为每个操作赋予唯一的事务ID。最后一次操作的事务ID还会被写入到文件（seen_txid），namenode重启后会读取这些信息，并在最后一次事务ID上继续递增。
每个edits文件的文件名都有固定的格式，其中当前正在写的文件名格式为edits_inprogress_TXID，TXID为该文件中记录的第一个操作的事务ID；已经写完成的editlog文件名为 edits_StartTXID_EndTXID，StartTXID为该文件中记录的第一个操作的事务ID，EndTXID为该文件中记录的最后一个操作的事务ID。

Edits文件内容

//每条记录是一条操作
<?xml version="1.0" encoding="UTF-8"?>
<EDITS>
	<EDITS_VERSION>-63</EDITS_VERSION>
	<RECORD>
		<OPCODE>OP_START_LOG_SEGMENT</OPCODE>
		<DATA>
			<TXID>129</TXID>
		</DATA>
	</RECORD>
	<RECORD>
		<OPCODE>OP_ADD</OPCODE>
		<DATA>
			<TXID>130</TXID>
			<LENGTH>0</LENGTH>
			<INODEID>16407</INODEID>
			<PATH>/hello7.txt</PATH>
			<REPLICATION>2</REPLICATION>
			<MTIME>1512943607866</MTIME>
			<ATIME>1512943607866</ATIME>
			<BLOCKSIZE>134217728</BLOCKSIZE>
			<CLIENT_NAME>DFSClient_NONMAPREDUCE_-1544295051_1</CLIENT_NAME>
			<CLIENT_MACHINE>192.168.1.5</CLIENT_MACHINE>
			<OVERWRITE>true</OVERWRITE>
			<PERMISSION_STATUS>
				<USERNAME>atguigu</USERNAME>
				<GROUPNAME>supergroup</GROUPNAME>
				<MODE>420</MODE>
			</PERMISSION_STATUS>
			<RPC_CLIENTID>908eafd4-9aec-4288-96f1-e8011d181561</RPC_CLIENTID>
			<RPC_CALLID>0</RPC_CALLID>
		</DATA>
	</RECORD>
	<RECORD>
		<OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
		<DATA>
			<TXID>131</TXID>
			<BLOCK_ID>1073741839</BLOCK_ID>
		</DATA>
	</RECORD>
	<RECORD>
		<OPCODE>OP_SET_GENSTAMP_V2</OPCODE>
		<DATA>
			<TXID>132</TXID>
			<GENSTAMPV2>1016</GENSTAMPV2>
		</DATA>
	</RECORD>
	<RECORD>
		<OPCODE>OP_ADD_BLOCK</OPCODE>
		<DATA>
			<TXID>133</TXID>
			<PATH>/hello7.txt</PATH>
			<BLOCK>
				<BLOCK_ID>1073741839</BLOCK_ID>
				<NUM_BYTES>0</NUM_BYTES>
				<GENSTAMP>1016</GENSTAMP>
			</BLOCK>
			<RPC_CLIENTID></RPC_CLIENTID>
			<RPC_CALLID>-2</RPC_CALLID>
		</DATA>
	</RECORD>
	<RECORD>
		<OPCODE>OP_CLOSE</OPCODE>
		<DATA>
			<TXID>134</TXID>
			<LENGTH>0</LENGTH>
			<INODEID>0</INODEID>
			<PATH>/hello7.txt</PATH>
			<REPLICATION>2</REPLICATION>
			<MTIME>1512943608761</MTIME>
			<ATIME>1512943607866</ATIME>
			<BLOCKSIZE>134217728</BLOCKSIZE>
			<CLIENT_NAME></CLIENT_NAME>
			<CLIENT_MACHINE></CLIENT_MACHINE>
			<OVERWRITE>false</OVERWRITE>
			<BLOCK>
				<BLOCK_ID>1073741839</BLOCK_ID>
				<NUM_BYTES>25</NUM_BYTES>
				<GENSTAMP>1016</GENSTAMP>
			</BLOCK>
			<PERMISSION_STATUS>
				<USERNAME>atguigu</USERNAME>
				<GROUPNAME>supergroup</GROUPNAME>
				<MODE>420</MODE>
			</PERMISSION_STATUS>
		</DATA>
	</RECORD>
</EDITS >

3.NN和Secondary NN工作机制(CheckPoint)

Checkpoint process

When the NameNode starts up, or a checkpoint is triggered by a configurable threshold,:

it reads the FsImage and EditLog from disk
it applies all the transactions from the EditLog to the in-memory representation of the FsImage
it flushes out this new version into a new FsImage on disk.
It truncates the old EditLog because its transactions have been applied to the persistent FsImage.

A checkpoint can be triggered:

at a given time interval (dfs.namenode.checkpoint.period) expressed in seconds,
or after a given number of filesystem transactions have accumulated (dfs.namenode.checkpoint.txns).

If both of these properties are set, the first threshold to be reached triggers a checkpoint.

From the config file:

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

<property>
  <name>dfs.namenode.checkpoint.txns</name>
  <value>1000000</value>
</property>

NN和Secondary NN机制

标签：Hdfs,NN,SecondaryNN,FsImage,Edits,文件,namenode,ID
来源： https://blog.csdn.net/weixin_43955361/article/details/113198032