SecondaryNameNode讲解

 

简介

HA的一个解决方案。但不支持热备。配置即可。

执行过程：从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，替换旧的fsimage.

默认在安装在NameNode节点上，但这样...不安全！

 

一、secondarynameNode工作原理

使用原因：

未使用secondarynameNode时，NameNode工作中会产生fsimage 和edtes,edits日志过大，直接导致集群二次开机恢复原本状态过慢，引起开机时间过长。

意义:

加快集群二次启动的速度（减小集群二次启动的时间）

 

帮助NameNode 周期性在NameNode节点拷贝fsimage 和edtes 到自己的节点上，进行合并，合并后生成全新的FSimage,最后将FSimage发送回NameNode.

1、 namenode通知secondaryNameNode进行合并操作

2、secondaryNameNode收到namenode的请求后(通过http方式)下载namenode中的FSImage和editlog到secondaryNameNode节点的机器中；

3、namenode收到secondaryNameNode的下载请求后，会再创建一个新的edits log ，此时客户端的操作日志都会写入这个新的edits log中，然后才会把旧的edits log 和原本的fsimage给secondaryNameNode；

4、secondaryNameNode收到edits log与fsimage后，将fsimage载入内存，会按照edits log里边记录的日志操作，一步一步执行里边的操作，把数据更新到fsimage文件中，等edits log里的所有操作都执行完了，此时的fsimage文件已经是最新的了，然后把新的fsimage返回给namenode；

在secondaryNameNode处理过程中，如果客户端进行了增删改操作，这些新的操作就会写入第3步中创建的新的edits log 中，不会修改已经被传到secondaryNameNode的旧的edits log。（这样可以保证在这个时候namenode宕机可以通过旧的fsimage+旧的editslog+新的edits log恢复元数据。）

5、namenode用新的fsimage替换旧的fsimage

secondarynameNode最好是一个独立的节点, 此节点的配置最好与NameNode 相同。

 

二、fsimage与editlog作用

fsimage保存了最新的元数据检查点，在HDFS启动时加载fsimage的信息，包含了整个HDFS文件系统的所有目录和文件的信息。

对于文件来说包括了数据块描述信息、修改时间、访问时间等；

对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。

editlog主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录，HDFS客户端执行所有的写操作都会被记录到editlog中。

 

三、设计好处

NameNode起来之后，HDFS中的更新操作会重新写到edits文件中，因为fsimage文件一般都很大（GB级别的很常见），如果所有的更新操作都往fsimage文件中添加，这样会导致系统运行的十分缓慢，对于更新操作都会记录在editlog中，

为了避免editlog不断增大，secondary namenode会周期性合并fsimage和edits成新的fsimage，新的操作记录会写入新的editlog中，这个周期可以自己设置（editlog到达一定大小或者定时）

 

四、fsimage与edits的合并时机

<!-- 默认一小时合并一次 ， 人为设置使用如下参数 --> 
dfs.namenode.checkpoint.period ：3600 

<!-- 默认100W次合并一次。人为设置使用如下参数 --> 
dfs.namenode.checkpoint.txns ： 1000000 

<!-- 还有一个参数是每隔多长时间检查一次hdfs的操作次数 -->
dfs.namenode.checkpoint.check.period ：60

 

五、如何查看fsimage和edits文件

使用命令 hdfs  oiv

cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current/ hdfs oiv -i fsimage_0000000000000000357 -p XML -o testa.xml

查看命令 hdfs  oev

cd  /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits/current hdfs oev -i  edits_0000000000000000865-0000000000000000866 -o myedit.xml -p XML

 

六、fsimage和edits的产生

NameNode元数据解析

（1）第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载edits和fsimage文件到内存。

（2）客户端对元数据进行增删改的请求。

（3）namenode记录操作日志，更新滚动日志。

（4）namenode在内存中对数据进行增删改查。

当namenode启动，元数据是如何生成？

fsimage和edits文件都是经过序列化的，在NameNode启动的时候，它会将fsimage文件中的内容加载到内存中，之后再执行edits文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。

例如：在启动HDFS时，只需要读入fsimage_0000000000000008927以及edits_inprogress_0000000000000008928就可以还原出当前hdfs的最新状况。

NameNode起来之后，HDFS的更新操作会重新写到edits文件中，因为fsimage文件一般都很大，如果所有的更新操作都往fsimage文件中添加，这样会导致系统运行缓慢但是如果往edits文件里面写就不会这样，每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新。如果一个文件比较大，使得写操作需要向多台机器进行操作，只有当所有的写操作都执行完成之后，写操作才会返回成功，这样的好处是任何的操作都不会因为机器的故障而导致元数据的不同步。

 

七、namenode元数据信息多目录配置

NameNode存储到元数据信息（fsimage 和edtes）可以多目录存储，防止元数据丢失。

hdfs-site.xml
<property>
   <name>dfs.namenode.name.dir</name>
   <value>
        file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas1,
        /export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas2,
        /export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas3,
        /export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/namenodeDatas4
   </value>
</property>

 

八、namenode故障恢复

secondaryNamenode对namenode当中的fsimage和edits进行合并时，每次都会先将namenode的fsimage与edits文件拷贝一份过来，所以fsimage与edits文件在secondarNamendoe当中也会保存有一份

如果namenode的fsimage与edits文件损坏，那么我们可以将secondaryNamenode当中的fsimage与edits拷贝过去给namenode继续使用，只不过有可能会丢失一部分数据

 

涉及到几个配置选项(namenode的fsimage和edits文件目录、secondaryNamenode的fsimage和edits文件目录)

<--  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进程

[root@node01 current]# jps
3009 NodeManager
2453 NameNode
7767 Jps
2714 SecondaryNameNode
2555 DataNode
2907 ResourceManager
[root@node01 current]# kill -9 2453

第二步：删除namenode的fsimage与edits文件

[root@node01 current]# rm -rf /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/*
[root@node01 current]# rm -rf /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits/*

第三步：拷贝 secondaryNamenode 的 fsimage 与 edits 文件到 namenode 的 fsimage 与 edits 文件夹下面去

[root@node01 current]# 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/
[root@node01 current]# 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

[root@node01 current]# cd /export/servers/hadoop-2.6.0-cdh5.14.0/
[root@node01 hadoop-2.6.0-cdh5.14.0]# sbin/hadoop-daemon.sh start namenode
starting namenode, logging to /export/servers/hadoop-2.6.0-cdh5.14.0/logs/hadoop-root-namenode-node01.out

第五步：浏览器页面正常访问

ip + 50070

192.168.100.131:50070/explorer.html#/

 

HDFS 新增节点与删除节点