文章目录
目标:掌握Fsumage和Edits的作用
1.NameNode元数据解析
1.预备知识
元数据(Metadata),又称中介数据、中继数据,为描述数据的数据(data about data),主要是描述数据属性(property)的信息,用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。
2.元数据的解析
1.第一次启动namenode格式化后,创建fsimage和edits文件。如果不是第一次启动,直接加载edits和fsimage文件到内存
2.客户端对元数据进行增删改的请求
3.namenode记录操作日志,更新滚动日志
4.namenode在内存中对数据进行增删改查。
2.Fsimage和Edits的作用
fsimage保存了最新的元数据检查点,在HDFS启动时加载fsimage的信息,包含了整个HDFS文件系统的所有目录和文件的信息。
对于文件来说包括了数据块描述信息、修改时间、访问时间等。
对于目录来说包括修改时间、访问权限控制信息(目录所属用户,所在组)等。
editlog主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录,HDFS客户端执行所有的写操作都会被记录到editlog中。
Fsimage,editlog主要用于在集群启动时将集群的状态恢复到关闭前的状态。
为了达到这个目的,集群启动时将Fsimage、editlog加载到内存中,进行合并,合并后恢复完成。
3.元数据信息目录的配置
hdfs-site.xml当中:
<property>
<name>dfs.namenode.name.dir</name>
<value>
file://hadoop软件包所在路径/HadoopDatas/namenodeDatas
</value>
</property>
<property>
<name>dfs.namenode.edits.dir</name>
<value>
file://hadoop软件包所在路径/HadoopDatas/dfs/nn/edits
</value>
</property>
4.FSimage文件当中的文件信息查看
1.将fsimage文件转为xml文件:
hdfs oiv -i fsimage文件绝对路径 -p XML -o hello.xml
2.查看文件信息
cat hello.xml
5.edits当中的文件信息查看
1.将edits文件转为xml文件
hdfs oev -i edits文件绝对路径 -o myedit.xml -p XML
2.查看文件信息
cat myedit.xml
6.SecondarynameNode如何辅助管理FSImage与Edits文件
目标:掌握secondaynameNode是如何辅助nameNode合并Fsimage和Edits的
SecondarynameNode产生背景:
1.由于editlog记录了集群运行期间所有对HDFS的相关操作,所以这个文件会很大。
2.集群关闭后再次启动时会将Fsimage,editlog加载到内存中,进行合并,恢复到集群的。
3.由于editlog文件很大所有,集群再次启动时会花费较长时间。
4.为了加快集群的启动时间,所以使用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
注:
1.完成合并的是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。
2.Hadoop进入安全模式时需要管理员使用dfsadmin的save namespace来创建新的检查点。
3.secondarynamenode在合并edits和fsimage时需要消耗的内存和namenode差不多,所以一般把namenode和secondarynamenode放在不同的机器上。
7.fsimage与edits的合并周期影响因素
1.时间因素:默认一个小时为一个周期fsimage与edits合并一次
2.次数因素:当hdfs次数达到1000000 也会触发合并
3.以60s为一个周期,当hdfs的操作次数超过1000000 也会触发合并
8.namenode元数据信息多目录配置
目的:为了保证元数据的安全性,我们一般都是先确定好我们的磁盘挂载目录,将元数据的磁盘做RAID1,每个目录存放内容相同,增加了可靠性。
配置:
hdfs-site.xml
<property>
<name>dfs.namenode.name.dir</name>
<value>
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>
9.namenode故障恢复
目标:掌握nameNode故障后如何恢复
secondaryNamenode对namenode当中的fsimage和edits进行合并时,每次都会先将namenode的fsimage与edits文件拷贝一份过来,所以fsimage与edits文件在secondarNamendoe当中也会保存有一份,如果namenode的fsimage与edits文件损坏,那么我们可以将secondaryNamenode当中的fsimage与edits拷贝过去给namenode继续使用,只不过有可能会丢失一部分数据。这里涉及到几个配置选项
1.namenode保存fsimage的配置路径
<property>
<name>dfs.namenode.name.dir</name>
<value>file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas</value>
</property>
2.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>
3.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>
4.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>
5.故障恢复步骤
1.杀死namenode进程
2.删除namenode的fsimage与edits文件
3.拷贝secondaryNamenode的fsimage与edits文件到namenode的fsimage与edits文件夹下面去
4.启动namenode
5.浏览器页面正常访问
注:当在Secondaynamenode周期内操作的新操作日志和元数据没有保存在secondaryNamenode中,若在周期外,则代表新数据已经保存在secondaryNamenode中。