Namenode 与 SecondaryNameNode

1、HDFS元数据管理机制

问题1:NameNode如何管理和存储元数据?

  • 计算机中存储数据两种:内存或者是磁盘
  • 元数据存储磁盘:存储磁盘无法面对客户端对元数据信息的任意的快速低延迟的响应,但是安全性高
  • 元数据存储内存:元数据存放内存,可以高效的查询以及快速响应客户端的查询请求,数据保存在内存,如果断点,内存中的数据全部丢失。

解决方案:内存+磁盘;NameNode内存+FsImage的文件(磁盘)

新问题:磁盘和内存中元数据如何划分?

两个数据一模一样,还是两个数据合并到一起才是一份完整的数据呢?

  • 一模一样:client如果对元数据进行增删改操作,需要保证两个数据的一致性。FsImage文件操作起来效率也不高。
  • 两个合并=完整数据:NameNode引入了一个edits文件(日志文件:只能追加写入)edits文件记录的是client的增删改操作,不再选择让NameNode把数据dump出来形成FsImage文件(这种操作是比较消耗资源)。

元数据管理流程图

第一阶段:NameNode启动 

  • 第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
  • 客户端对元数据进行增删改的请求。
  • NameNode记录操作日志,更新滚动日志。
  • NameNode在内存中对数据进行增删改。

第二阶段:Secondary NameNode工作

  • Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否执行检查点操作结果。
  • Secondary NameNode请求执行CheckPoint。
  • NameNode滚动正在写的Edits日志。
  • 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
  • Secondary NameNode加载编辑日志和镜像文件到内存,并合并。
  • 生成新的镜像文件fsimage.chkpoint。
  • 拷贝fsimage.chkpoint到NameNode。
  • NameNode将fsimage.chkpoint重新命名成fsimage。

2、Fsimage与Edits文件解析

        NameNode在执行格式化之后,会在/opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current目录下产生如下文件

  • Fsimage文件:是namenode中关于元数据的镜像,一般称为检查点,这里包含了HDFS文件系统所有目录以及文件相关信息(Block数量,副本数量,权限等信息)
  • Edits文件 :存储了客户端对HDFS文件系统所有的更新操作记录,Client对HDFS文件系统所有的更新操作都会被记录到Edits文件中(不包括查询操作)
  • seen_txid:该文件是保存了一个数字,数字对应着最后一个Edits文件名的数字
  • VERSION:该文件记录namenode的一些版本号信息,比如:CusterId,namespaceID等 

(1) Fsimage文件内容

官方地址 

https://hadoop.apache.org/docs/r2.9.2/hadoop-project-dist/hadoophdfs/HdfsImageViewer.html

因为Fsimg中保存的内容是二进制数据,我们必须通过工具将他进行转化后才能阅读 

查看oiv和oev命令

基本语法

hdfs oiv -p 文件类型(xml) -i 镜像文件 -o 转换后文件输出路径

案例实操

[root@linux121 current]$ cd /opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current


[root@linux121 current]$ hdfs oiv -p XML -i fsimage_0000000000000000265 -o
/opt/lagou/servers/fsimage.xml


[root@linux121 current]$ cat /opt/lagou/servers/fsimage.xml

这样我们打开xml文件就能阅读其内容

问题:Fsimage中为什么没有记录块所对应DataNode?

        在内存元数据中是有记录块所对应的dn信息,但是fsimage中就剔除了这个信息;HDFS集群在启动的时候会加载image以及edits文件,block对应的dn信息都没有记录,集群启动时会有一个安全模式(safemode),安全模式就是为了让dn汇报自己当前所持有的block信息给nn来补全元数据。后续每隔一段时间dn都要汇报自己持有的block信息。 

(2)Edits文件内容

基本语法

hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径

案例实操

[root@linux121 current]$ hdfs oev -p XML -i edits_0000000000000000266-0000000000000000267 -o /opt/lagou/servers/hadoop-2.9.2/edits.xml


[root@linux121 current]$ cat /opt/lagou/servers/hadoop-2.9.2/edits.xml

备注:Edits中只记录了更新相关的操作,查询或者下载文件并不会记录在内!!

问题:NameNode启动时如何确定加载哪些Edits文件呢?

        nn启动时需要加载fsimage文件以及那些没有被2nn进行合并的edits文件,nn如何判断哪些edits已经被合并了呢?

可以通过fsimage文件自身的编号来确定哪些已经被合并。

(3) checkpoint周期

[hdfs-default.xml]

<!-- 定时一小时 -->
<property>
    <name>dfs.namenode.checkpoint.period</name>
    <value>3600</value>
</property>

<!-- 一分钟检查一次操作次数,当操作次数达到1百万时,SecondaryNameNode执行一次 -->
<property>
    <name>dfs.namenode.checkpoint.txns</name>
    <value>1000000</value>
    <description>操作动作次数</description>
</property>
<property>
    <name>dfs.namenode.checkpoint.check.period</name>
    <value>60</value>
    <description> 1分钟检查一次操作次数</description>
</property >

3、NameNode故障处理

        NameNode故障后,HDFS集群就无法正常工作,因为HDFS文件系统的元数据需要由NameNode来管理维护并与Client交互,如果元数据出现损坏和丢失同样会导致NameNode无法正常工作进而HDFS文件系统无法正常对外提供服务。

如果元数据出现丢失损坏如何恢复呢?

  1. 将2NN的元数据拷贝到NN的节点下(此种方式会存在元数据的丢失。)
  2. 搭建HDFS的HA(高可用)集群,解决NN的单点故障问题!!(借助Zookeeper实现HA,一个Active的NameNode,一个是Standby的NameNode)
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

悠然予夏

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值