前言

最近刚接触Hadoop, 一直没有弄明白NameNode和Secondary NameNode的区别和关系。很多人都认为，Secondary NameNode是NameNode的备份，是为了防止NameNode的单点失败的，直到读了这篇文章Secondary Namenode - What it really do? (需翻墙)才发现并不是这样。文章写的很通俗易懂，现将其翻译如下：

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

在Hadoop中，有一些命名不好的模块，Secondary NameNode是其中之一。从它的名字上看，它给人的感觉就像是NameNode的备份。但它实际上却不是。很多Hadoop的初学者都很疑惑，Secondary NameNode究竟是做什么的，而且它为什么会出现在HDFS中。因此，在这篇文章中，我想要解释下Secondary NameNode在HDFS中所扮演的角色。

从它的名字来看，你可能认为它跟NameNode有点关系。没错，你猜对了。因此在我们深入了解Secondary NameNode之前，我们先来看看NameNode是做什么的。

NameNode

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

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

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

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

edit logs文件会变的很大，怎么去管理这个文件是一个挑战。
NameNode的重启会花费很长时间，因为有很多改动[笔者注:在edit logs中]要合并到fsimage文件上。
如果NameNode挂掉了，那我们就丢失了很多改动因为此时的fsimage文件非常旧。[笔者注: 笔者认为在这个情况下丢失的改动不会很多, 因为丢失的改动应该是还在内存中但是没有写到edit logs的这部分。]

因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。

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

Secondary NameNode

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

上面的图片展示了Secondary NameNode是怎么工作的。

首先，它定时到NameNode去获取edit logs，并更新到fsimage上。[笔者注：Secondary NameNode自己的fsimage]
一旦它有了新的fsimage文件，它将其拷贝回NameNode中。
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工作原理

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

SecondaryNameNode通知NameNode准备提交edits文件，此时主节点产生edits.new
SecondaryNameNode通过http get方式获取NameNode的fsimage与edits文件（在SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）
SecondaryNameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt
SecondaryNameNode用http post方式发送fsimage.ckpt至NameNode
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为单独节点时需要设置。

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。步骤如下：

准备原来机器一样的机器，包括配置和文件
创建一个空的文件夹，该文件夹就是配置文件中dfs.name.dir所指向的文件夹。
拷贝你的secondary NameNode checkpoint出来的文件，到某个文件夹，该文件夹为fs.checkpoint.dir指向的文件夹（例如：/home/hadadm/clusterdir/tmp/dfs/namesecondary）
执行命令bin/hadoop namenode –importCheckpoint
这样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可以解决这个问题

Secondary NameNode:它究竟有什么作用？（转自：http://blog.csdn.net/xh16319/article/details/31375197）相关推荐

Secondary Namenode的Check point机制以及Namenode、Datanode工作机制说明
目录前言: 1.NameNode的工作机制 2.DataNode的工作机制 3.Secondary Namenode的Check point机制目录前言: 在说明checkpoint机制之前,先 ...
Hadoop中的Namenode、Datanode和Secondary Namenode
1.namenode Namenode 管理着文件系统的Namespace.它维护着文件系统树(filesystem tree)以及文件树中所有的文件和文件夹的元数据(metadata),比如命名空间 ...
加密软件究竟有哪些作用呢？
信息化时代,企业数据泄露事件层出不穷,给企业及个人造成了一定的危机.大家开始担心自身数据安全,以及数据信息安全如何维护?伴随着数据泄露事件的发生,加密软件应运而生,并且市场上繁多的加密品牌,也成为人们 ...
模拟namenode挂掉利用secondary namenode恢复
测试机器: 10.0.50.144 master (namenode,datanode) 10.0.50.145 node1 (datanode) 10.0.50.146 node2 ...
口琴膜片什么作用_思域发动机舱里的这个东西是什么东东，它究竟有什么作用呢？...
今天的文章我们主要来讲讲图中的这个东西究竟是什么?你们知道他是干什么的吗,这个东西究竟有什么作用? 这是前几天的一个微信网友添加我微信问我的问题,今天对这个问题整理了一下,顺来来科普一下关于这个系 ...
简明扼要的HDFS元数据管理机制描述（NameNode和Secondary NameNode工作机制）
目录一.思考: NameNode中的元数据是存储在哪里? 二.NameNode和Secondary NameNode工作机制三.Fsimage和Edits概念一.思考: NameNode中的元数 ...
软件测试究竟发挥什么作用？
软件测试究竟发挥什么作用? 有人简单回答说,软件测试就是发现缺陷.但软件测试仅仅就是为了发现缺陷吗?绝对不是. 软件测试有它的验证作用,就是人们经常说的V&V,Verification 验证产 ...
Secondary NameNode和Standby NameNde的区别
Secondary NameNode: HDFS单NameNode节点的情况下(即非高可用HA),Secondary NameNode负责每隔一段时间将旧的fsimage文件和edits log文件m ...
Hadoop——使用secondary namenode数据恢复namenode
secondary namenode会定期将fsimage和edits从namenode上拉取进行合并,且在在secondary nemenode上有副本,当namenode节点损坏后,我们可以通过这 ...

Secondary NameNode:它究竟有什么作用？（转自：http://blog.csdn.net/xh16319/article/details/31375197）

前言

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

NameNode

Secondary NameNode

后记

Hadoop Namenode和Secondary Namenode

Secondarynamenode作用

Secondarynamenode工作原理

相关配置文件

Secondarynamenode工作原理图

Secondary NameNode:它究竟有什么作用？（转自：http://blog.csdn.net/xh16319/article/details/31375197）相关推荐

最新文章

热门文章