Big DataHDFS讲义(3)
文章目录
- 5、Fsimage 和 Edits
- HDFS元数据信息目录的配置选项
- FSimage文件当中的文件信息查看
- edits当中的文件信息查看
- secondarynameNode 如何辅助管理FSImage与Edits文件
- secondarynameNode什么时候进行文件拷贝合并
- namenode元数据信息多目录配置
- namenode故障恢复
- 故障恢复步骤方式一
- 故障恢复步骤方式二
5、Fsimage 和 Edits
-
fsimage保存了最新的元数据检查点,在HDFS启动时加载fsimage的信息,包含了整个HDFS文件系统的所有目录和文件的信息。
对于文件来说包括了数据块描述信息、修改时间、访问时间等。
对于目录来说包括修改时间、访问权限控制信息(目录所属用户,所在组)等。 -
editlog主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录,HDFS客户端执行所有的写操作都会被记录到editlog中。
-
Fsimage,editlog主要用于在集群启动时将集群的状态恢复到关闭前的状态。
为了达到这个目的,集群启动时将Fsimage、editlog加载到内存中,进行合并,合并后恢复完成。
NameNode元数据解析
(1)第一次启动namenode格式化后,创建fsimage和edits文件。如果不是第一次启动,直接加载edits和fsimage文件到内存。
(2)客户端对元数据进行增删改的请求。
(3)namenode记录操作日志,更新滚动日志。
(4)namenode在内存中对数据进行增删改查。
总结
- Fsimage 记录HDFS文件系统的镜像或快照(周期性记录)(此文件相对较小)
- Edits 记录客户端对进行的所有的增、删、改、追加等操作(没有使用Secondary NameNode之前,不是周期性生 成)(此文件相对较大)
- Fsimage Edits作用:用于还原集群上次关闭时的状态。还原时将两个文件加载到内存,检查、合并最终生成一个新 的Fsimage 。原本的Edits失效。
HDFS元数据信息目录的配置选项
在配置文件hdfs-site.xml中记录了两个文件的存放位置。
注意:大小写字母和路径是否一致
[root@node01 hadoop]# vim hdfs-site.xml
# Fsimage <name>为key <value>为value
<property><name>dfs.namenode.name.dir</name><value>
file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas
</value>
</property>
# Edits <name>为key <value>为value
<property><name>dfs.namenode.edits.dir</name><value>
file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/dfs/nn/edits
</value>
</property>
总结
Fsimage 的存放路径:dfs.namenode.name.dir
edits日志存放的路径:dfs.namenode.edits.dir
FSimage文件当中的文件信息查看
- 将Fsimage转换成xml
[root@node01 ~]# cd /export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas/current[root@node01 current]# hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml
# 导出到桌面
[root@node01 current]# sz hello.xml
edits当中的文件信息查看
- 将 Edits转换成xml
[root@node01 ~]# cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits/current[root@node01 current]# hdfs oev -i edits_0000000000000000157-0000000000000000158 0000158 -p XML -o test01.xml[root@node01 current]# sz test01.xml
secondarynameNode 如何辅助管理FSImage与Edits文件
由于editlog记录了集群运行期间所有对HDFS的相关操作,所以这个文件会很大。
集群关闭后再次启动时会将Fsimage,editlog加载到内存中,进行合并,恢复到集群的。
由于editlog文件很大所有,集群再次启动时会花费较长时间。
为了加快集群的启动时间,所以使用secondarynameNode辅助NameNode合并Fsimage,editlog。
- 原理如下
- 1、 secnonaryNN通知NameNode切换editlog
2、secondaryNN从NameNode中获得FSImage和editlog(通过http方式)
3、secondaryNN将FSImage载入内存,然后开始合并editlog,合并之后成为新的fsimage
4、secondaryNN将新的fsimage发回给NameNode
5、NameNode用新的fsimage替换旧的fsimage
完成合并的是secondarynamenode,会请求namenode停止使用edits,暂时将新写操作放入一个新的文件中(edits.new)。secondarynamenode从namenode中通过http get获得edits,因为要和fsimage合并,所以也是通过http get 的方式把fsimage加载到内存,然后逐一执行具体对文件系统的操作,与fsimage合并,生成新的fsimage,然后把fsimage发送给namenode,通过http post的方式。namenode从secondarynamenode获得了fsimage后会把原有的fsimage替换为新的fsimage,把edits.new变成edits。
Hadoop进入安全模式时需要管理员使用dfsadmin的save namespace来创建新的检查点。
secondarynamenode在合并edits和fsimage时需要消耗的内存和namenode差不多,所以一般把namenode和secondarynamenode放在不同的机器上
总结
- 前提:不使用SNN,日志文件会很大,日志大会导致集群恢复到上次关机前的状态花费很长时间,这个时候集群处于 安全模式,集群不可用。长时间处于安全模式。
- 目标:加快集群二次启动的速度。(减少集群二次启动的时间)
- SecondaryNamenode周期性复制NameNode的FSIMAGE 和edits到本机(SecondaryNamenode本机),将两个文 件进行合并,最终生成全新的Fsimage,将最新的Fsimage发送回Namenode 。
- 意义:辅助NameNode合并Fsimage Edits.减小了日志的大小,加快了集群的二次启动速度
- SecondaryNamenode自己独立部署在有一个节点上。此节点的配置要与NameNode相同
secondarynameNode什么时候进行文件拷贝合并
fsimage与edits的合并时机取决于两个参数
- 1.第一个参数是默认1小时fsimage与edits合并一次
2.第二个参数是hdfs操作次数达到1000000 也会触发合并
第一个参数:时间达到一个小时fsimage与edits就会进行合并
dfs.namenode.checkpoint.period :3600第二个参数:hdfs操作达到1000000次也会进行合并
dfs.namenode.checkpoint.txns :1000000还有一个参数是每隔多长时间检查一次hdfs的操作次数
dfs.namenode.checkpoint.check.period :60
- 只以最后一个版本为准
Fsimage 1 2 3 4 5
Edits 1 2 3 4 5
总结
SecondaryNamenode将 Namenode的Fsimage Edits拷贝过来以后,在本地同样进行保存。
- SecondaryNamenode存储Namenode的 Fsimage 的配置 使用 < name>dfs.namenode.checkpoint.dir</ name>为key,路径为value
- SecondaryNamenode存储Namenode的 Edits 的配置 使用 < name>dfs.namenode.checkpoint.edits.dir< name> 为key ,路径为value
namenode元数据信息多目录配置
为了保证元数据的安全性,我们一般都是先确定好我们的磁盘挂载目录,将元数据的磁盘做RAID1
namenode的本地目录可以配置成多个,且每个目录存放内容相同,增加了可靠性。
2)具体配置如下:
[root@node01 hadoop]# vim hdfs-site.xml
<property><name>dfs.namenode.name.dir</name>
<value> #注意路径的大小写是否一致 file://可以不加
file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas,
file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas,
file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas,
file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas
</value>
</property>
每个目录配置到独立的磁盘上
namenode故障恢复
secondaryNamenode对namenode当中的fsimage和edits进行合并时,每次都会先将namenode的fsimage与edits文件拷贝一份过来,所以fsimage与edits文件在secondarNamendoe当中也会保存有一份,如果namenode的fsimage与edits文件损坏,那么我们可以将secondaryNamenode当中的fsimage与edits拷贝过去给namenode继续使用,只不过有可能会丢失一部分数据。这里涉及到几个配置选项
- namenode保存fsimage的配置路径
<property><name>dfs.namenode.name.dir</name><value>file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas</value>
</property>
namenode保存edits文件的配置路径
<property><name>dfs.namenode.edits.dir</name><value>file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/dfs/nn/edits</value>
</property>
- secondaryNamenode保存fsimage文件的配置路径
<property><name>dfs.namenode.checkpoint.dir</name><value>file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/dfs/snn/name</value>
</property>
secondaryNamenode保存edits文件的配置路径
<property><name>dfs.namenode.checkpoint.edits.dir</name><value>file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/dfs/nn/snn/edits</value>
</property>
故障恢复步骤方式一
- 第一步:杀死namenode进程
使用jps查看namenode进程号,然后直接使用kill -9 进程号杀死namenode进程
[root@node01 install]# jps
127156 QuorumPeerMain
127785 ResourceManager
17688 NameNode
127544 SecondaryNameNode
127418 DataNode
128365 JobHistoryServer
19036 Jps
127886 NodeManager
# kill -9 杀死namenode进程
[root@node01 install]# kill -9 17688
- 第二步:删除namenode的fsimage与edits文件
namenode所在机器执行以下命令,删除fsimage与edits文件
删除fsimage与edits文件
rm -rf /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/*rm -rf /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits/*
- 第三步:拷贝secondaryNamenode的fsimage与edits文件到namenode的fsimage与edits文件夹下面去
将secondaryNameNode所在机器的fsimage与edits文件拷贝到namenode所在的fsimage与edits文件夹下面去。
由于我的secondaryNameNode与namenode安装在同一台机器,都在node01上面,node01执行以下命令进行拷贝
拷贝:fsimage目录下的所有
cp -r /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/snn/name/* /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/拷贝:Edits目录下的所有
cp -r /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/snn/edits/* /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits
- 第四步:启动namenode
node01服务器执行以下命令启动namenode
[root@node01 /]cd hadoop-2.6.0-cdh5.14.0/启动namenode
[root@node01 hadoop-2.6.0-cdh5.14.0/]# sbin/hadoop-daemon.sh start namenode
- 第五步:浏览器页面正常访问
http://node01:50070
http://192.168.100.201:50070
故障恢复步骤方式二
- 1、集群关机,关闭NameNode
#jps查看namenode
[root@node01 /]# jps
4800 NodeManager
4289 NameNode
4705 ResourceManager
4563 SecondaryNameNode
31563 Jps
4413 DataNode
# 关闭NameNode
[root@node01/]# ./stop-all.sh
- 2、将NameNode的Fsimage Edits日志全部删除
删除Fsimage
rm -rf /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current/* 删除Edits
rm -rf /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits/current/*
- 3、开机验证是否可以启动
启动集群
[root@node01 sbin]# ./start-all.sh
# 查看 NameNode 不存在
[root@node01 /]# jps
4800 NodeManager
4705 ResourceManager
4563 SecondaryNameNode
31563 Jps
4413 DataNode
查看日志
vi /export/servers/hadoop-2.6.0-cdh5.14.0/logs/hadoop-root-namenode-node01.log
- 4、在SN拷贝Fsimage Edits到NameNode
拷贝Fsimage
cp /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/snn/name/current/* /export/servers/hadoop2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current/拷贝Edits
cp /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/snn/edits/current/* /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits/current/
- 5、重新启动集群
#启动集群
[root@node01 sbin]# ./start-all.sh
#jps查看NameNode 是否存在
[root@node01 /]# jps
4800 NodeManager
4289 NameNode
4705 ResourceManager
4563 SecondaryNameNode
31563 Jps
4413 DataNode
发布评论