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为单独节点时需要设置。
相关配置文件
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。步骤如下：
- 准备原来机器一样的机器，包括配置和文件
- 创建一个空的文件夹，该文件夹就是配置文件中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可以解决这个问题
在初学Hadoop时，有个让人疑惑的概念：Secondary NameNode，也叫辅助namenode。从命名看，好像是第二个namenode，用于备份主namenode，在主namenode失败后启动。那么，Secondary NameNode的作用是什么？是如何工作的？
一，NameNode
HDFS集群有两类节点以管理者和工作者的工作模式运行，namenode就是其中的管理者。它管理着文件系统的命名空间，维护着文件系统树及整棵树的所有文件和目录。这些信息以两个文件的形式保存于内存或者磁盘，这两个文件是：命名空间镜像文件fsimage和编辑日志文件edit logs ，同时namenode也记录着每个文件中各个块所在的数据节点信息。
namenode对元数据的操作过程 
图中有两个文件：
（1）fsimage:文件系统映射文件，也是元数据的镜像文件（磁盘中），存储某段时间namenode内存元数据信息。
（2）edits log:操作日志文件。
这种工作方式的特点：
（1）namenode始终在内存中存储元数据（metedata）,使得“读操作”更加快、
（2）有“写请求”时，向edits文件写入日志，成功返回后才修改内存，并向客户端返回。
（3）fsimage文件为metedata的镜像，不会随时同步，与edits合并生成新的fsimage。
从以上特点可以知道，edits文件会在集群运行的过程中不断增多，占用更多的存储空间，虽然有合并，但是只有在namenode重启时才会进行。并且在实际工作环境很少重启namenode，
这就带来了一下问题：
（1）edits文件不断增大，如何存储和管理？
（2）因为需要合并大量的edits文件生成fsimage，导致namenode重启时间过长。
（3）一旦namenode宕机，用于恢复的fsiamge数据很旧，会造成大量数据的丢失。
二，Secondary NameNode
上述问题的解决方案就是运行辅助namenode–Secondary NameNode，为主namenode内存中的文件系统元数据创建检查点，Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份，
SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并。两个过程同时进行，称为checkpoint（检查点）。
镜像备份的作用：备份fsimage(fsimage是元数据发送检查点时写入文件)；
日志与镜像的定期合并的作用：将Namenode中edits日志和fsimage合并,防止如果Namenode节点故障，namenode下次启动的时候，会把fsimage加载到内存中，应用edits log,edits log往往很大，导致操作往往很耗时。（这也是namenode容错的一套机制）
Secondary NameNode创建检查点过程
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过程到此结束。
SecondaryNameNode备份由三个参数控制fs.checkpoint.period控制周期（以秒为单位，默认3600秒），fs.checkpoint.size控制日志文件超过多少大小时合并（以字节为单位，默认64M）， dfs.http.address表示http地址，这个参数在SecondaryNameNode为单独节点时需要设置。
从工作过程可以看出，SecondaryNameNode的重要作用是定期通过编辑日志文件合并命名空间镜像，以防止编辑日志文件过大。SecondaryNameNode一般要在另一台机器上运行，因为它需要占用大量的CPU时间与namenode相同容量的内存才可以进行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启用。
