1. 元数据加载
为了保证交互速度,HDFS文件系统的metadata是被load到namenode机器的内存中的。
并会将内存中的这些数据保存到磁盘进行持久化存储,但对块的位置信息不进行持久化存储,在DataNode向namenode进行注册时动态加载。
当NameNode启动时,它从硬盘中读取Editlog和FsImage。将所有Editlog中的事务作用在内存中的FsImage上,以恢复HDFS重启之前的最终状态。这个时候系统处于safemode,在等待DataNode上报的block数据块位置信息达到namenode中所存储的0.99999的时候才会退出。
将这个新版本的FsImage从内存中保存到本地磁盘上,然后删除旧的Editlog,因为旧的Editlog的事务都已经作用在FsImage上了。这个过程称为一个检查点(checkpoint)。
在内存中保存文件系统中每个文件和每个数据块的引用关系(文件、block、datanode之间的映射信息)
2. 元数据存储
如果元数据仅以文件的形式存储在namenode本地硬盘行不行呢?
因为大批量的客户端同时在进行上传、下载等各种操作时,都要对元数据进行读写及修改操作
仅仅以文件的形式来存储元数据显然不行,因为无法做到对各种操作的快速响应
把元数据放在内存中呢,确实能够提高系统响应速度,但是一旦断电就完全丢失了,这肯定也不行
那么如果把内存的数据定期flush到磁盘文件的方法行不行呢?
一旦断电,没来得及的刷到磁盘的内存数据肯定也是要丢失的,显然也不行
那么在实际环境中,hadoop是怎么管理元数据的呢?
首先,磁盘确实有块空间,对元数据进行持久化存储的,名为fsimage
如果直接读取磁盘文件,速度肯定跟不上,内存中也要放一些元数据信息
虽然很容易丢失,但可以提供查询服务,实际上就是读写分离,由读写分离就有了数据一致性的问题
因为写入数据,没有写入内存中,最新的元数据记录在哪呢?
实际上是记录在edits.log中,这个文件不提供修改,只提供追加,以日志的形式记录
比如在上传一个文件时,先对namenode进行询问,往哪里写,namenode一边分配一边记录
将空间分配信息记录edits.log,当完成一个副本的写入工作后,通知namenode,被认为是写入成功
这时,将edits.log的数据更新至内存,此时,内存中的数据是最新的
即使现在断电,最新的元数据在edits.log也有保存。
当客户端执行写操作时,NameNode会先在编辑日志中写下记录,并在内存中保存一个文件系统元数据
元数据会在编辑日志有所改动后进行更新。内存中的元数据用来提供读数据请求服务
过程分析:
namenode在内存中保存了整个文件系统的命名空间和文件块映射表
客户端写入文件时,NameNode首先在edits.log文件中记录元数据操作
操作完成后将成功信息发送给NameNode。NameNode在内存中写入这次操作新产生的元数据信息
更新的顺序edits.log-----内存-----fsimage
fsimage合并操作:
为防止影响响应速度,由SecondaryNamenode来合并
当edits*.log大小达到64M或时间达到1h时,通知SecondaryNamenode进行checkpoint操作
3. 元数据恢复
恢复数据两种方式:
第一种:把namesecondary/current中的内容直接复制到name目录下。
第二种:通过secondarynamenode来使用import checkpoint。如果开通了这个选项进行namenode恢复的话,系统会将secondarynamenode作为当前的namenode。也会把SNN中的元数据信息作为系统的元数据信息。
第一种:
在hadoopdata/dfs目录下可以看到name文件夹和namesecondary文件夹。
进入namesecondary/current文件夹,可以看到edits,fsimage,VERSION,和namenode中的内容相同。
第二种:Import Checkpoint
如果namenode宕机,硬盘数据需要时间恢复或者不能恢复了。这个时候就可以import checkpoint。
步骤如下:
1.准备与原namenode一样的机器,包括配置和文件。
2.创建一个空的文件夹,为配置文件中dfs.name.dir所指向的文件夹。
3.拷贝SecondaryNameNode checkpoint出来的文件到fs.checkpoint.dir指向的文件夹
4.执行命令hadoop namenode -importCheckpoint
5.NameNode会读取checkpoint文件,保存到dfs.name.dir。
但是如果dfs.name.dir之前已经包含fsimage文件(非导入),是会执行失败的。
因为NameNode会检查fs.checkpoint.dir目录下镜像的一致性,但是不会去改动它。
还提供了另外两种方法来做checkpoint:Checkpoint Node和Backup Node。
Checkpoint Node和Backup Node在后续版本中hadoop-0.21.0出现了。
这两种方式要比通过secondaryNameNode来做checkpoint好很多。
Checkpoint Node像是secondaryNameNode的改进替代版,Backup Node提供更大的便利。