开发者社区> smartloli> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

解读Secondary NameNode的功能

简介:
+关注继续查看

1.概述

  最近有朋友问我Secondary NameNode的作用,是不是NameNode的备份?是不是为了防止NameNode的单点问题?确实,刚接触Hadoop,从字面上看,很容易会把Secondary NameNode当作备份节点;其实,这是一个误区,我们不能从字面来理解,阅读官方文档,我们可以知道,其实并不是这么回事,下面就来赘述下Secondary NameNode的作用。

2.Secondary NameNode?

  在Hadoop中,有一些命名模块不那么尽人意,Secondary NameNode就是一个典型的例子之一。从它的名字上看,它给人的感觉就像是NameNode的备份节点,但实际上却不是。很多Hadoop的入门者都很疑惑,Secondary NameNode究竟在其中起什么作用,它在HDFS中所扮演的角色是什么。下面,我就来解释下:

  从名字来看,它确实与NameNode有点关系;因此,在深入了解Secondary NameNode之前,我们先来看看NameNode是做什么的。

2.1NameNode

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

  上图展示来NameNode怎么把元数据保存到磁盘上,这里有两个不同的文件:

  • fsimage:它是NameNode启动时对整个文件系统的快照。
  • edits:它是在NameNode启动后,对文件系统的改动序列。

  只有在NameNode重启时,edits才会合并到fsimage文件中,从而得到一个文件系统的最新快照。但是在生产环境集群中的NameNode是很少重启的,这意味者当NameNode运行来很长时间后,edits文件会变的很大。在这种情况下就会出现下面这些问题:

  1. edits文件会变的很大,如何去管理这个文件?
  2. NameNode的重启会花费很长的时间,因为有很多改动要合并到fsimage文件上。
  3. 如果NameNode宕掉了,那我们就丢失了很多改动,因为此时的fsimage文件时间戳比较旧。

  因此为了克服这个问题,我们需要一个易于管理的机制来帮助我们减小edits文件的大小和得到一个最新的fsimage文件,这样也会减小在NameNode上的压力。而Secondary NameNode就是为了帮助解决上述问题提出的,它的职责是合并NameNode的edits到fsimage文件中。如图所示:

  上图的工作原理,我这里也赘述下:

  1. 首先,它定时到NameNode去获取edits,并更新到fsimage上。
  2. 一旦它有新的fsimage文件,它将其拷贝回NameNode上。
  3. NameNode在下次重启时回使用这个新的fsimage文件,从而减少重启的时间。

  Secondary NameNode的整个目的在HDFS中提供一个Checkpoint Node,通过阅读官方文档可以清晰的知道,它只是NameNode的一个助手节点,这也是它在社区内被认为是Checkpoint Node的原因。

  现在,我们明白Secondary NameNode所做的是在文件系统这设置一个Checkpoint来帮助NameNode更好的工作;它不是取代NameNode,也不是NameNode的备份。  

  Secondary NameNode的检查点进程启动,是由两个配置参数控制的:

  • fs.checkpoint.period,指定连续两次检查点的最大时间间隔, 默认值是1小时。
  • fs.checkpoint.size定义了edits日志文件的最大值,一旦超过这个值会导致强制执行检查点(即使没到检查点的最大时间间隔)。默认值是64MB。

  如果NameNode上除了最新的检查点以外,所有的其他的历史镜像和edits文件都丢失了, NameNode可以引入这个最新的检查点。以下操作可以实现这个功能:

  • 在配置参数dfs.name.dir指定的位置建立一个空文件夹;
  • 把检查点目录的位置赋值给配置参数fs.checkpoint.dir;
  • 启动NameNode,并加上-importCheckpoint。

  NameNode会从fs.checkpoint.dir目录读取检查点,并把它保存在dfs.name.dir目录下。如果dfs.name.dir目录下有合法的镜像文件,NameNode会启动失败。 NameNode会检查fs.checkpoint.dir目录下镜像文件的一致性,但是不会去改动它。

  注:关于NameNode是什么时候将改动写到edit logs中的?这个操作实际上是由DataNode的写操作触发的,当我们往DataNode写文件时,DataNode会跟NameNode通信,告诉NameNode什么文件的第几个block放在它那里,NameNode这个时候会将这些元数据信息写到edit logs文件中。

  下面附上官方文档说明:


The NameNode stores modifications to the file system as a log appended to a native file system file, edits. When a NameNode starts up, it reads HDFS state from an image file, fsimage, and then applies edits from the edits log file. It then writes new HDFS state to the fsimage and starts normal operation with an empty edits file. Since NameNode merges fsimage and edits files only during start up, the edits log file could get verylarge over time on a busy cluster. Another side effect of a larger edits file is that next restart of NameNode takes longer.

  The secondary NameNode merges the fsimage and the edits log files periodically and keeps edits log size within a limit. It is usually run ona different machine than the primary NameNode since its memory requirements are on the same order as the primary NameNode.

  The start of the checkpoint process on the secondary NameNode is controlled by two configuration parameters.

* dfs.namenode.checkpoint.period, set to 1 hour by default, specifies the maximum delay between two consecutive checkpoints, and
* dfs.namenode.checkpoint.txns, set to 1 million by default, defines the number of uncheckpointed transactions on the NameNode which will force   an urgent checkpoint, even if the checkpoint period has not been reached.
  The secondary NameNode stores the latest checkpoint in a directory which is structured the same way as the primary NameNode's directory. So that the check pointed image is always ready to be read by the primary NameNode if necessary.

  参考地址:http://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html

3.总结

  这篇文章就和大家分享到这里,若在阅读过程中有什么疑问,可以加群进行讨论或发送邮件给我,我会尽我所能为您解答,与君共勉!


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
SAP RETAIL 通过自动补货功能触发的采购申请有些啥特殊的地方?
SAP RETAIL 通过自动补货功能触发的采购申请有些啥特殊的地方?
33 0
阿里云ECS搭建FTP服务
阿里云ECS搭建FTP服务
381 0
【由浅至深】redis 实现发布订阅的几种方式
原文:【由浅至深】redis 实现发布订阅的几种方式 非常感谢依乐祝发表文章《.NET Core开发者的福音之玩转Redis的又一傻瓜式神器推荐》,对csredis作了一次完整的诠释。 前言 提到消息队列,最熟悉无疑是 rabbitmq,它基本是业界标准的解决方案。
1492 0
MongoDB副本集--Secondary节点恢复实例
MongoDB副本集中有一台Secondary节点出现RECOVERING的状态 点击(此处)折叠或打开 arps:RECOVERING> rs.
1482 0
MongoDB Secondary 延时高(同步锁)问题分析
背景介绍 MongoDB 复制集里 Secondary 不断从主上批量拉取 oplog,然后在本地重放,以保证数据与 Primary 一致。同步原理参考MongoDB复制集同步原理解析 Secondary 拉取到一批 oplog 后,在重放这批 oplog 时,会加一个特殊的 Lock::ParallelBatchWriterMode 的锁,这个锁会阻塞所有的读请求,直到这批 oplog 重放完成。
6412 0
Mongodb 通过一致性备份搭建SECONDARY.
该方法应用面比较窄, 适用于 : 一主 一备 一投票节点,数据库较大,oplog 比较小,备库需要修复而且主库不能停机的情况.
3327 0
MongoDB Secondary同步慢问题分析(续)
在MongoDB Scondary同步慢问题分析文中介绍了因Primary上写入qps过大,导致Secondary节点的同步无法追上的问题,本文再分享一个case,因oplog的写入被放大,导致同步追不上的问题。 MongoDB用于同步的oplog具有一个重要的『幂等』特性,也就是说,一条oplo
6003 0
阿里云 redhat 5.4下lnmp 配置笔记
redhat-release.x86_64 0:5Server-5.4.0.3   一、挂在数据盘 1、ssh登录 2、fdisk -l 3、硬盘分区 fdisk /dev/xvdb    n    p    w    检查分区fdisk -l 4、硬盘格式化mkfs.ext3 /dev/xvdb1 5、mkdir alidata && mount /d
1518 0
+关注
smartloli
笔名:哥不是小萝莉 博客园地址:http://www.cnblogs.com/smartloli/
162
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载