Secondary NameNode 的做用

https://blog.csdn.net/xh16319/article/details/31375197

不少人都认为，Secondary NameNode是NameNode的备份，是为了防止NameNode的单点失败的，其实并非这样。

Secondary NameNode:它究竟有什么做用？

在Hadoop中，有一些命名很差的模块，Secondary NameNode是其中之一。从它的名字上看，它给人的感受就像是NameNode的备份。但它实际上却不是。不少Hadoop的初学者都很疑惑，Secondary NameNode到底是作什么的，并且它为何会出如今HDFS中。所以，在这篇文章中，我想要解释下Secondary NameNode在HDFS中所扮演的角色。

从它的名字来看，你可能认为它跟NameNode有点关系。没错，你猜对了。所以在咱们深刻了解Secondary NameNode以前，咱们先来看看NameNode是作什么的。

NameNode

NameNode主要是用来保存HDFS的元数据信息，好比命名空间信息，块信息等。当它运行的时候，这些信息是存在内存中的。可是这些信息也能够持久化到磁盘上。

上面的这张图片展现了NameNode怎么把元数据保存到磁盘上的。这里有两个不一样的文件：

1. fsimage - 它是在NameNode启动时对整个文件系统的快照
2. edit logs - 它是在NameNode启动后，对文件系统的改动序列

只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而获得一个文件系统的最新快照。可是在产品集群中NameNode是不多重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。在这种状况下就会出现下面一些问题：

1. edit logs文件会变的很大，怎么去管理这个文件是一个挑战。
2. NameNode的重启会花费很长时间，由于有不少改动[笔者注:在edit logs中]要合并到fsimage文件上。
3. 若是NameNode挂掉了，那咱们就丢失了不少改动由于此时的fsimage文件很是旧。[笔者注: 笔者认为在这个状况下丢失的改动不会不少, 由于丢失的改动应该是还在内存中可是没有写到edit logs的这部分。]

所以为了克服这个问题，咱们须要一个易于管理的机制来帮助咱们减少edit logs文件的大小和获得一个最新的fsimage文件，这样也会减少在NameNode上的压力。这跟Windows的恢复点是很是像的，Windows的恢复点机制容许咱们对OS进行快照，这样当系统发生问题时，咱们可以回滚到最新的一次恢复点上。

如今咱们明白了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。那么，这些跟Secondary NameNode又有什么关系呢？

Secondary NameNode

SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。

上面的图片展现了Secondary NameNode是怎么工做的。

1. 首先，它定时到NameNode去获取edit logs，并更新到fsimage上。[笔者注：Secondary NameNode本身的fsimage]
2. 一旦它有了新的fsimage文件，它将其拷贝回NameNode中。
3. NameNode在下次重启时会使用这个新的fsimage文件，从而减小重启的时间。

Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的缘由。

如今，咱们明白了Secondary NameNode所作的不过是在文件系统中设置一个检查点来帮助NameNode更好的工做。它不是要取代掉NameNode也不是NameNode的备份。因此从如今起，让咱们养成一个习惯，称呼它为检查点节点吧。

 

后记

这篇文章基本上已经清楚的介绍了Secondary NameNode的工做以及为何要这么作。最后补充一点细节，是关于NameNode是何时将改动写到edit logs中的？这个操做其实是由DataNode的写操做触发的，当咱们往DataNode写文件时，DataNode会跟NameNode通讯，告诉NameNode什么文件的第几个block放在它那里，NameNode这个时候会将这些元数据信息写到edit logs文件中。

 

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hadoop Namenode和Secondary Namenode

Secondarynamenode做用

SecondaryNameNode有两个做用，一是镜像备份，二是日志与镜像的按期合并。两个过程同时进行，称为checkpoint. 镜像备份的做用:备份fsimage(fsimage是元数据发送检查点时写入文件);日志与镜像的按期合并的做用:将Namenode中edits日志和fsimage合并,防止(若是Namenode节点故障，namenode下次启动的时候，会把fsimage加载到内存中，应用edit log,edit log每每很大，致使操做每每很耗时。)

Secondarynamenode工做原理

日志与镜像的按期合并总共分五步：

1. SecondaryNameNode通知NameNode准备提交edits文件，此时主节点产生edits.new
2. SecondaryNameNode经过http get方式获取NameNode的fsimage与edits文件（在SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）
3. SecondaryNameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt
4. SecondaryNameNode用http post方式发送fsimage.ckpt至NameNode
5. NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits，而后更新fstime，整个checkpoint过程到此结束。 在新版本的hadoop中（hadoop0.21.0）,SecondaryNameNode两个做用被两个节点替换， checkpoint node与backup node. SecondaryNameNode备份由三个参数控制fs.checkpoint.period控制周期，fs.checkpoint.size控制日志文件超过多少大小时合并， dfs.http.address表示http地址，这个参数在SecondaryNameNode为单独节点时须要设置。

相关配置文件

core-site.xml：这里有2个参数可配置，但通常来讲咱们不作修改。fs.checkpoint.period表示多长时间记录一次hdfs的镜像。默认是1小时。fs.checkpoint.size表示一次记录多大的size，默认64M。

<property><name>fs.checkpoint.period</name> <value>3600</value> <description>The number of seconds between two periodic checkpoints. </description> </property>   <property> <name>fs.checkpoint.size</name> <value>67108864</value> <description>The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs.checkpoint.period hasn’t expired. </description> </property>

镜像备份的周期时间是能够修改的，若是不想一个小时备份一次，能够改的时间短点。core-site.xml中的fs.checkpoint.period值

Secondarynamenode工做原理图

这也解释了下面的问题：

(1)、为何namenode和Secondary namenode须要一样大内存

(2)、大集群中namenode和Secondary namenode须要是各自独立的两个节点。

Checkpoint的日志信息

2011-07-19 23:59:28,435 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 02011-07-19 23:59:28,472 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Downloaded file fsimage size 548 bytes. 2011-07-19 23:59:28,473 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Downloaded file edits size 631 bytes. 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: fsOwner=hadadm,hadgrp 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: supergroup=supergroup 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: isPermissionEnabled=true 2011-07-19 23:59:28,488 INFO org.apache.hadoop.hdfs.server.common.Storage: Number of files = 6 2011-07-19 23:59:28,489 INFO org.apache.hadoop.hdfs.server.common.Storage: Number of files under construction = 0 2011-07-19 23:59:28,490 INFO org.apache.hadoop.hdfs.server.common.Storage: Edits file /home/hadadm/clusterdir/tmp/dfs/namesecondary/current/edits of size 631 edits # 6 loaded in 0 seconds. 2011-07-19 23:59:28,493 INFO org.apache.hadoop.hdfs.server.common.Storage: Image file of size 831 saved in 0 seconds. 2011-07-19 23:59:28,513 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 0 2011-07-19 23:59:28,543 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Posted URL master:50070putimage=1&port=50090&machine=10.253.74.234&token=-18:1766583108:0:1311091168000:1311087567797 2011-07-19 23:59:28,561 WARN org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Checkpoint done. New Image Size: 831

 Namenode/Secondarynamenode文件结构

[hadadm@slave /home/hadadm/clusterdir/tmp/dfs/namesecondary/current]$ ll 总用量 24 drwxr-xr-x  2 hadadm hadgrp 4096  7月 19 22:59 ./ drwxr-xr-x  5 hadadm hadgrp 4096  7月 19 23:59 ../ -rw-r–r–  1 hadadm hadgrp    4  7月 19 23:59 edits -rw-r–r–  1 hadadm hadgrp  548  7月 19 22:59 fsimage -rw-r–r–  1 hadadm hadgrp    8  7月 19 22:59 fstime -rw-r–r–  1 hadadm hadgrp  101  7月 19 22:59 VERSION   [hadadm@slave /home/hadadm/clusterdir/tmp/dfs/namesecondary/current] $ cat VERSION #Tue Jul 19 22:59:27 CST 2011 namespaceID=1766583108 cTime=0 storageType=NAME_NODE layoutVersion=-18 推这里VERSION表示的是secondarynamenode中的fsimage版本是22:59时的;加上edits应用的日志就能够到23:59

[hadadm@master /home/hadadm/clusterdir/dfs/name/current]$ ls -l 总用量 16 -rw-r–r–  1 hadadm hadgrp   4  7月 19 23:59 edits -rw-r–r–  1 hadadm hadgrp 831  7月 19 23:59 fsimage -rw-r–r–  1 hadadm hadgrp   8  7月 19 23:59 fstime -rw-r–r–  1 hadadm hadgrp 101  7月 19 23:59 VERSION   [hadadm@master /home/hadadm/clusterdir/dfs/name/current] $ cat VERSION #Tue Jul 19 23:59:28 CST 2011 namespaceID=1766583108 cTime=0 storageType=NAME_NODE layoutVersion=-18 这里VERSION表示的是namenode中的fsimage版本是23:59时的; edits应用没有变动 这里的fsimage至关于secondarynamenode里面的fsimage+edits

[hadadm@slave /home/hadadm/clusterdir/tmp/dfs/namesecondary]$ ls -l 总用量 12 drwxr-xr-x  2 hadadm hadgrp 4096  7月 19 23:59 current drwxr-xr-x  2 hadadm hadgrp 4096  7月 19 22:59 image -rw-r–r–  1 hadadm hadgrp    0  7月 19 23:59 in_use.lock drwxr-xr-x  2 hadadm hadgrp 4096  7月 19 22:59 previous.checkpoint   [hadadm@slavea /home/hadadm/clusterdir/tmp/dfs/namesecondary] $ ls -l previous.checkpoint/ 总用量 16 -rw-r–r–  1 hadadm hadgrp   4  7月 19 23:59 edits -rw-r–r–  1 hadadm hadgrp 548  7月 19 22:59 fsimage -rw-r–r–  1 hadadm hadgrp   8  7月 19 22:59 fstime -rw-r–r–  1 hadadm hadgrp 101  7月 19 22:59 VERSION 这里上一个检查点的数据是能够用来恢复数据的

Import Checkpoint（恢复数据）

若是主节点namenode挂掉了，硬盘数据须要时间恢复或者不能恢复了，如今又想马上恢复HDFS，这个时候就能够import checkpoint。步骤以下：

1. 准备原来机器同样的机器，包括配置和文件
2. 建立一个空的文件夹，该文件夹就是配置文件中dfs.name.dir所指向的文件夹。
3. 拷贝你的secondary NameNode checkpoint出来的文件，到某个文件夹，该文件夹为fs.checkpoint.dir指向的文件夹（例如：/home/hadadm/clusterdir/tmp/dfs/namesecondary）
4. 执行命令bin/hadoop namenode –importCheckpoint
5. 这样NameNode会读取checkpoint文件，保存到dfs.name.dir。可是若是你的dfs.name.dir包含合法的 fsimage，是会执行失败的。由于NameNode会检查fs.checkpoint.dir目录下镜像的一致性，可是不会去改动它。

通常建议给maste配置多台机器，让namesecondary与namenode不在同一台机器上值得推荐的是，你要注意备份你的dfs.name.dir和 ${hadoop.tmp.dir}/dfs/namesecondary。

后续版本中的backupnode

Checkpoint Node 和 Backup Node在后续版本中hadoop-0.21.0，还提供了另外的方法来作checkpoint：Checkpoint Node 和 Backup Node。则两种方式要比secondary NameNode好不少。因此 The Secondary NameNode has been deprecated. Instead, consider using the Checkpoint Node or Backup Node. Checkpoint Node像是secondary NameNode的改进替代版，Backup Node提供更大的便利，这里就再也不介绍了。

BackupNode ： 备份结点。这个结点的模式有点像 mysql 中的主从结点复制功能， NN 能够实时的将日志传送给 BN ，而 SNN 是每隔一段时间去 NN 下载 fsimage 和 edits 文件，而 BN 是实时的获得操做日志，而后将操做合并到 fsimage 里。在 NN 里提供了二个日志流接口： EditLogOutputStream 和 EditLogInputStream 。即当 NN 有日志时，不只会写一份到本地 edits 的日志文件，同时会向 BN 的网络流中写一份，当流缓冲达到阀值时，将会写入到 BN 结点上， BN 收到后就会进行合并操做，这样来完成低延迟的日志复制功能。 总结： 当前的备份结点都是冷备份，因此还须要实现热备份，使得 NN 挂了后，从结点自动的升为主结点来提供服务。 主 NN 的效率问题： NN 的文件过多致使内存消耗问题， NN 中文件锁问题， NN 的启动时间。

由于Secondarynamenaode不是实施备份和同步,因此SNN会丢掉当前namenode的edit log数据,应该来讲backupnode能够解决这个问题