HDFS文件系统和元数据合并流程以及namenode启动流程
一、HDFS文件系统(重要)
1、namenode:接收用户操作请求;维护文件系统的目录结构;管理文件与block之间的关系、block与datanode的关系,只存储元数据。
namenode管理:namenode支持对HDFS中的目录、文件和块block做出类似文件系统的创建、修改、删除、列出文件和目录等基本操作。
块存储管理 在整个HDFS集群中有且只有唯一一个处于active状态的namenode节点,该节点负责对这个命名空间HDFS进行管理。
元数据:描述数据的数据,含有(数据大小,创建时间,创建者等。。)
保存元数据文件包括:
fsImage
edits
·2、datanode:存储文件
文件被分成block块存储在磁盘上 为了保存数据安全,文件会有多个副本(默认为3个)。
namenode和client客户端的指令进行存储或者检索block,并且周期性的向namenode节点报告它存储在哪些文件的block。
·3、SecondaryNameNode:用于同步元数据信息与日志。
一、namenode启动流程和元数据合并流程
NameNode启动流程:
** 包含文件
edits 日志的元数据
记录NameNode运行期间所执行的操作
edits只做追加操作
fsImage 镜像元数据
** 加载fsImage和edits
** 重新生产fsImage和edits
** 等待DataNode注册和发送块报告
** 在启动过程中会进入安全模式
安全模式safeMode:
** 只能读取不能写入
** 作用:
保证数据安全性
** HDFS集群容量达到阀值0.999f
dfs.namenode.safemode.threshold-pct
SecondaryNameNode:
辅助NameNode合并edits和fsImage
它不是NameNode的热备HA
NameNode的元数据信息先往edits文件中写,当edits文件达到一定的阈值(3600秒或大小到128M)的时候,会开启合并的流程。
合并流程:
Namenode:只存储元数据
Fsimage(二进制文件):存储元数据
Editlog(存在多个,不是普通的文件):存储元数据。只做追加写入
SendaryNameNode:发送请求将Editlog合并到Fsimage,过程是通过HTTP GET下载fsimage和editlog 下载到secondaryNamenode所在的磁盘(当然在这个过程中namenode所在的磁盘会自动新生成fsimage和editlog),并合并到editlog.cdkt,并把这个cdkt文件复制到namenode所在的磁盘,然后将faimage.cdkt重命名为faimage。将原来的fsimage删除。
在第二次拉取过程中,直接只将editlog下载到secondary Namenode所在的磁盘。