Secondary NameNode和NameNode的关系

• 引入https://blog.csdn.net/u010846741/article/details/52369527
• https://blog.csdn.net/yangjjuan/article/details/71107012

在搭建hadoop集群的时候，都要配置Secondary NameNode的位置，大多数人可能就根据名字，认为Secondary NameNode就是第二名称节点，是在NameNode挂掉之后，Secondary NameNode启动充当名称节点，实际上并不是，Secondary NameNode的主要作用是检查点。

1，namenode

namenode是hadoop集群的管理者，它管理着文件系统的命名空间，维护着文件系统树及整棵树的所有文件和目录。这些信息以两个文件的形式保存于内存或者磁盘，这两个文件是：命名空间镜像文件fsimage和编辑日志文件edit logs ，同时namenode也记录着每个文件中各个块所在的数据节点信息。

在集群有写请求的时候，namenode向editlogs文件中写入日志，成功返回后才会写入内存，并向客户端返回，fsimage文件为metedata的镜像，不会随时同步，与edits合并生成新的fsimage。

从以上特点可以知道，edits文件会在集群运行的过程中不断增多，占用更多的存储空间，虽然有合并，但是只有在namenode重启时才会进行。并且在实际工作环境很少重启namenode，
这就带来了一下问题：
（1）edits文件不断增大，如何存储和管理？
（2）因为需要合并大量的edits文件生成fsimage，导致namenode重启时间过长。
（3）一旦namenode宕机，用于恢复的fsiamge数据很旧，会造成大量数据的丢失。

现在由此引出一个问题，namenode中的元数据是存储在哪里的？首先，我们做个假设，如果存储在namenode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断点，元数据丢失，整个集群就无法工作了！！！因此必须在磁盘中有备份，在磁盘中的备份就是fsImage，存放在namenode节点对应的磁盘中。这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新fsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦namenode节点断点，就会产生数据丢失。因此，引入edits.log文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到edits.log中。这样，一旦namenode节点断电，可以通过fsImage和edits.log的合并，合成元数据。但是，如果长时间添加数据到edit.log中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行fsImage和edits.log的合并，如果这个操作有namenode节点完成，又会效率过低。因此，引入一个新的节点secondaryNamenode，专门用于fsImage和edits.log的合并。

二，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容错的一套机制）

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发生故障时启用。