Big Data>HDFS讲义（3）

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