|
|
|
|
|
![[fe889daa8be54dcaa1c7cc364c7a35f5.png]]
|
|
|
|
|
|
|
|
|
|
|
|
# 一、概述
|
|
|
|
|
|
|
|
|
|
|
|
NameNode是整个文件系统的管理节点，它主要维护着整个文件系统的文件目录树，文件/目录的信息 和 每个文件对应的数据块列表，并且还负责接收用户的操作请求
|
|
|
|
|
|
|
|
|
|
|
|
### 文件目录树
|
|
|
|
|
|
表示目录之间的层级关系，就是我们在hdfs上执行ls命令可以看到的那个目录结构信息
|
|
|
|
|
|
|
|
|
|
|
|
### 文件/目录的信息
|
|
|
|
|
|
表示文件/目录的的一些基本信息，所有者 属组 修改时间 文件大小等信息
|
|
|
|
|
|
|
|
|
|
|
|
### 数据块列表
|
|
|
|
|
|
如果一个文件太大，那么在集群中存储的时候会对文件进行切割，这个时候就类似于会给文件分成一块一块的，存储到不同机器上面。所以HDFS还要记录一下一个文件到底被分了多少块，每一块都在什么地方存储着
|
|
|
|
|
|
|
|
|
|
|
|
# 二、元数据文件
|
|
|
|
|
|
+ fsimage：元数据镜像文件，存储某一时段NameNode内存元数据信息
|
|
|
|
|
|
+ edits：操作日志文件
|
|
|
|
|
|
+ seen_txid：是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候，会按照seen_txid的数字，顺序从头跑edits_0000001~到seen_txid的数字。如果根据对应的seen_txid无法加载到对应的文件，NameNode进程将不会完成启动以保护数据一致性。
|
|
|
|
|
|
+ VERSION：保存了集群的版本信息
|
|
|
|
|
|
|
|
|
|
|
|
根据hdfs-site.xml文件配置，找到dfs.namenode.name.dir属性，可以找到元数据目录$dfs.namenode.name.dir/current
|
|
|
|
|
|
![[Snipaste_2023-03-06_10-26-39 1.png]]
|
|
|
|
|
|
in_use.lock 这个只是一个普通文件，但是它其实有特殊的含义，文件名后缀值lock 表示是锁的意思，文件名是in_use 表示这个文件现在正在使用，不允许你再启动namenode。当我们启动namonde的时候 会判断这个目录下是否有in_use.lock 这个相当于一把锁，如果没有的话，才可以启动成功，启动成功之后就会加一把锁， 停止的时候会把这个锁去掉。
|
|
|
|
|
|
![[Snipaste_2023-03-06_10-26-39.png]]
|
|
|
|
|
|
|
|
|
|
|
|
## 2.1 fsimage
|
|
|
|
|
|
fsimage文件有两个文件名相同的，有一个后缀是md5，md5是一种加密算法，这个其实主要是为了做md5校验的，为了保证文件传输的过程中不出问题，相同内容的md5是一样的，所以后期如果我把这个fsimage和对应的fsimage.md5发给你 然后你根据md5对fsimage的内容进行加密，获取一个值 和fsimage.md5中的内容进行比较，如果一样，说明你接收到的文件就是完整的。
|
|
|
|
|
|
|
|
|
|
|
|
通过命令将fsimage转为xml，方便查看
|
|
|
|
|
|
```shell
|
|
|
|
|
|
hdfs oiv -p XML -i fsimage_0000000000000000056 -o fsimage56.xml
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
里面最外层是一个fsimage标签，看里面的inode标签，
|
|
|
|
|
|
这个inode表示是hdfs中的每一个目录或者文件信息
|
|
|
|
|
|
```xml
|
|
|
|
|
|
<inode>
|
|
|
|
|
|
<id>16393</id>
|
|
|
|
|
|
<type>FILE</type>
|
|
|
|
|
|
<name>LICENSE.txt</name>
|
|
|
|
|
|
<replication>2</replication>
|
|
|
|
|
|
<mtime>1586332513657</mtime>
|
|
|
|
|
|
<atime>1586332513485</atime>
|
|
|
|
|
|
<preferredBlockSize>134217728</preferredBlockSize>
|
|
|
|
|
|
<permission>root:supergroup:0644</permission>
|
|
|
|
|
|
<blocks>
|
|
|
|
|
|
<block>
|
|
|
|
|
|
<id>1073741827</id>
|
|
|
|
|
|
<genstamp>1003</genstamp>
|
|
|
|
|
|
<numBytes>150569</numBytes>
|
|
|
|
|
|
</block>
|
|
|
|
|
|
</blocks>
|
|
|
|
|
|
<storagePolicyId>0</storagePolicyId>
|
|
|
|
|
|
</inode>
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
id：唯一编号
|
|
|
|
|
|
type：文件类型
|
|
|
|
|
|
name：文件名称
|
|
|
|
|
|
replication：文件的副本数量
|
|
|
|
|
|
mtime：修改时间
|
|
|
|
|
|
atime：访问时间
|
|
|
|
|
|
preferredBlockSize：推荐每一个数据块的大小
|
|
|
|
|
|
permission：权限信息
|
|
|
|
|
|
blocks：包含多少数据块【文件被切成数据块】
|
|
|
|
|
|
block：内部的id表示是块id，genstamp是一个唯一编号，numBytes表示当前数据块的实际大小，storagePolicyId表示是数据的存储策略
|
|
|
|
|
|
|
|
|
|
|
|
**这个文件中其实就维护了整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表，所以说fsimage中存放了hdfs最核心的数据。**
|
|
|
|
|
|
|
|
|
|
|
|
## 2.2 edits
|
|
|
|
|
|
当我们上传大文件的时候，一个大文件会分为多个block，那么edits文件中就会记录这些block的上传状态，只有当全部block都上传成功了以后，这个时候edits中才会记录这个文件上传成功了，那么我们执行hdfs dfs -ls 的时候就能查到这个文件了，所以当我们在hdfs中执行ls命令的时候，其实会查询fsimage和edits中的内容。
|
|
|
|
|
|
|
|
|
|
|
|
查看edits文件：
|
|
|
|
|
|
```shell
|
|
|
|
|
|
hdfs oev -i edits_0000000000000000057-0000000000000000065 -o edits.xml
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
OP_ADD：执行上传操作
|
|
|
|
|
|
OP_ALLOCATE_BLOCK_ID：申请block块id
|
|
|
|
|
|
OP_SET_GENSTAMP_V2：设置GENSTAMP
|
|
|
|
|
|
OP_ADD_BLOCK：添加block块
|
|
|
|
|
|
OP_CLOSE：关闭上传操作
|
|
|
|
|
|
|
|
|
|
|
|
```xml
|
|
|
|
|
|
<RECORD>
|
|
|
|
|
|
<OPCODE>OP_ADD</OPCODE>
|
|
|
|
|
|
<DATA>
|
|
|
|
|
|
<TXID>58</TXID>
|
|
|
|
|
|
<LENGTH>0</LENGTH>
|
|
|
|
|
|
<INODEID>16396</INODEID>
|
|
|
|
|
|
<PATH>/user.txt</PATH>
|
|
|
|
|
|
<REPLICATION>3</REPLICATION>
|
|
|
|
|
|
<MTIME>1586349095694</MTIME>
|
|
|
|
|
|
<ATIME>1586349095694</ATIME>
|
|
|
|
|
|
<BLOCKSIZE>134217728</BLOCKSIZE>
|
|
|
|
|
|
<CLIENT_NAME>DFSClient_NONMAPREDUCE_-1768454371_1</CLIENT_NAME>
|
|
|
|
|
|
<CLIENT_MACHINE>192.168.182.1</CLIENT_MACHINE>
|
|
|
|
|
|
<OVERWRITE>true</OVERWRITE>
|
|
|
|
|
|
<PERMISSION_STATUS>
|
|
|
|
|
|
<USERNAME>yehua</USERNAME>
|
|
|
|
|
|
<GROUPNAME>supergroup</GROUPNAME>
|
|
|
|
|
|
<MODE>420</MODE>
|
|
|
|
|
|
</PERMISSION_STATUS>
|
|
|
|
|
|
<ERASURE_CODING_POLICY_ID>0</ERASURE_CODING_POLICY_ID>
|
|
|
|
|
|
<RPC_CLIENTID>1722b83a-2dc7-4c46-baa9-9fa956b755cd</RPC_CLIENTID>
|
|
|
|
|
|
<RPC_CALLID>0</RPC_CALLID>
|
|
|
|
|
|
</DATA>
|
|
|
|
|
|
</RECORD>
|
|
|
|
|
|
<RECORD>
|
|
|
|
|
|
<OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
|
|
|
|
|
|
<DATA>
|
|
|
|
|
|
<TXID>59</TXID>
|
|
|
|
|
|
<BLOCK_ID>1073741830</BLOCK_ID>
|
|
|
|
|
|
</DATA>
|
|
|
|
|
|
</RECORD>
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
每一个record都有一个事务id，txid，事务id是连续的（从58到59，正常情况下有5个步骤，所以有5个连续的txid），其实一个put操作会在edits文件中产生很多的record，对应的就是很多步骤，这些步骤对我们是屏蔽的。
|
|
|
|
|
|
|
|
|
|
|
|
## 2.3 seen_txid
|
|
|
|
|
|
![[Snipaste_2023-03-06_10-26-39 3.png]]
|
|
|
|
|
|
seen_txid文件，HDFS format之后是0，它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候，会按照seen_txid的数字，顺序从头跑edits_0000001~到seen_txid的数字。如果根据对应的seen_txid无法加载到对应的文件，NameNode进程将不会完成启动以保护数据一致性。
|
|
|
|
|
|
|
|
|
|
|
|
## 2.4 VERSION
|
|
|
|
|
|
![[Snipaste_2023-03-06_10-26-39 2.png]]
|
|
|
|
|
|
|
|
|
|
|
|
# 三、SNN合并日志
|
|
|
|
|
|
edits隔一段时间就会对fsimage进行同步(合并)。edits在执行读写合并操作时，是被占用状态，整个namenode不能对外提供服务。用户一来会先找edits。这样不好。namenode是整个集群的管理和元数据记录。读写操作消耗很大。合并这件事可以定期发送给SecondaryNameNode来做。为了保证实时提供服务创建新的edits临时替代原来的edits对外提供服务。SecondaryNameNode的fsimage和edits合并后得到新的fsimage(SecondaryNameNode的edits被删除)传回给namenode，namenode的edits被清空。
|
|
|
|
|
|
|
|
|
|
|
|
![[5128967-24284b0c0ed22be3.png]]
|
