HADOOP集群NAMENODE工作机制

20人阅读 评论(0) 收藏 举报
分类:

NAMENODE工作机制

学习目标:理解namenode的工作机制尤其是元数据管理机制,以增强对HDFS工作原理的理解,及培养hadoop集群运营中“性能调优”、“namenode”故障问题的分析解决能力

NAMENODE职责:

        负责客户端请求的响应

        元数据的管理(查询,修改)

1、元数据管理

    namenode对数据的管理采用了三种存储形式:

        内存元数据(NameSystem)

        磁盘元数据镜像文件

        数据操作日志文件(可通过日志运算出元数据)

1.1 元数据存储机制

A、内存中有一份完整的元数据(内存meta data)

B、磁盘有一个“准完整”的元数据镜像(fsimage)文件(namenode的工作目录中)

C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件注:当客户端对hdfs中的文件进行新增或者修改操作,操作记录首先被记入edits日志文件中,当客户端操作成功后,相应的元数据会更新到内存meta.data

1.2 元数据手动查看

可以通过的一个工具来查看edits中的信息

bin/hdfs oev -i edits -o edits.xml
bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml

2.3 元数据的checkpoint

每隔一段时间,会由secondary namenodenamenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程称为checkpoint

checkpoint的详细过程


checkpoint操作的触发条件配置参数

dfs.namenode.checkpoint.check.period=60  #检查触发条件是否满足的频率,60

dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary

#以上两个参数做checkpoint操作时,secondary namenode的本地工作目录

dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}

 

dfs.namenode.checkpoint.max-retries=3  #最大重试次数

dfs.namenode.checkpoint.period=3600  #两次checkpoint之间的时间间隔3600

dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录

checkpoint的附带作用

namenodesecondary namenode的工作目录存储结构完全相同,所以,当namenode故障退出需要重新恢复时,可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录,以恢复namenode的元数据

2.4 元数据目录说明

在第一次部署好Hadoop集群的时候,我们需要在NameNodeNN)节点上格式化磁盘:

$HADOOP_HOME/bin/hdfs namenode -format

格式化完成之后,将会在$dfs.namenode.name.dir/current目录下如下的文件结构

current/
|-- VERSION
|-- edits_*
|-- fsimage_0000000000008547077
|-- fsimage_0000000000008547077.md5
`-- seen_txid

其中的dfs.name.dir是在hdfs-site.xml文件中配置的,默认值如下:


dfs.namenode.name.dir
属性可以配置多个目录, 

<property>
  <name>dfs.name.dir</name>
  <value>file://${hadoop.tmp.dir}/dfs/name</value>
</property>

hadoop.tmp.dir是在core-site.xml中配置的,默认值如下
<property>
  <name>hadoop.tmp.dir</name>
  <value>/tmp/hadoop-${user.name}</value>
  <description>A base for other temporary directories.</description>
</property>

/data1/dfs/name,/data2/dfs/name,/data3/dfs/name,....。各个目录存储的文件结构和内容都完全一样,相当于备份,这样做的好处是当其中一个目录损坏了,也不会影响到Hadoop的元数据,特别是当其中一个目录是NFS(网络文件系统Network File SystemNFS)之上,即使你这台机器损坏了,元数据也得到保存。
下面对$dfs.namenode.name.dir/current/目录下的文件进行解释。
1
VERSION文件是Java属性文件,内容大致如下:

#Fri Nov 15 19:47:46 CST 2013
namespaceID=934548976
clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196
cTime=0
storageType=NAME_NODE
blockpoolID=BP-893790215-192.168.24.72-1383809616115
layoutVersion=-47


其中
  (1)、namespaceID是文件系统的唯一标识符,在文件系统首次格式化之后生成的;
  (2)、storageType说明这个文件存储的是什么进程的数据结构信息(如果是DataNodestorageType=DATA_NODE);
  (3)、cTime表示NameNode存储时间的创建时间,由于我的NameNode没有更新过,所以这里的记录值为0,以后对NameNode升级之后,cTime将会记录更新时间戳;
  (4)、layoutVersion表示HDFS永久性数据结构的版本信息,只要数据结构变更,版本号也要递减,此时的HDFS也需要升级,否则磁盘仍旧是使用旧版本的数据结构,这会导致新版本的NameNode无法使用;
  (5)、clusterID是系统生成或手动指定的集群ID,在-clusterid选项中可以使用它;如下说明

 

a、使用如下命令格式化一个Namenode

$HADOOP_HOME/bin/hdfs namenode -format[-clusterId <cluster_id>]

选择一个唯一的cluster_id,并且这个cluster_id不能与环境中其他集群有冲突。如果没有提供cluster_id,则会自动生成一个唯一的ClusterID

b、使用如下命令格式化其他Namenode

 $HADOOP_HOME/bin/hdfs namenode -format-clusterId <cluster_id>

c、升级集群至最新版本。在升级过程中需要提供一个ClusterID,例如:

$HADOOP_PREFIX_HOME/bin/hdfs startnamenode --config $HADOOP_CONF_DIR  -upgrade -clusterId <cluster_ID>

如果没有提供ClusterID,则会自动生成一个ClusterID

  (6)、blockpoolID:是针对每一个Namespace所对应的blockpoolID,上面的这个BP-893790215-192.168.24.72-1383809616115就是在我的ns1namespace下的存储块池的ID,这个ID包括了其对应的NameNode节点的ip地址。

2
$dfs.namenode.name.dir/current/seen_txid非常重要,是存放transactionId的文件,format之后是0,它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候,会按照seen_txid的数字,循序从头跑edits_0000001~seen_txid的数字。所以当你的hdfs发生异常重启的时候,一定要比对seen_txid内的数字是不是你edits最后的尾数,不然会发生建置namenodemetaData的资料有缺少,导致误删Datanode上多余Block的资讯。

3$dfs.namenode.name.dir/current目录下在format的同时也会生成fsimageedits文件,及其对应的md5校验文件。

 

补充:seen_txid

文件中记录的是edits滚动的序号,每次重启namenode时,namenode就知道要将哪些edits进行加载edits



1、发送更新元数据请求,更新内存。
2、实时记录操作日志edits。
3、secondary namenode向namenode请求是否需要合并:checkpoint。
4、namenode滚动当前正在写的edits。
5、下载fsimage、edits到内存中,根据元数据算法,把记录重放,合并更新后的元数据,dump元数据,生成fsimgae.chkpoint文件。
6、secondary namenode上传fsimage.chkpoint文件到namenode,并同时修改文件名字为fsimage。

查看评论

hadoop namenode工作机制

转自:http://blog.csdn.net/u010846741/article/details/52369527 Hadoop 集群中有两种节点,一种是namenode,还...
  • u013808288
  • u013808288
  • 2016-11-05 09:20:49
  • 1344

hadoop namenode的工作机制

hadoop 集群中有两种节点,一种是namenode,还有一种是datanode。 其中datanode主要负责数据的存储,namenode主要负责三个功能,分别是(1)管理元数据  (2)维护目录...
  • u010846741
  • u010846741
  • 2016-08-30 15:14:11
  • 3157

hadoop的NAMENODE的管理机制,工作机制和DATANODE的工作原理

1:分布式文件系统(Distributed File System): (1):数据量越来越多,在一个操作系统管辖的范围存不下了,那么就分配到更多的操作系统管理的磁盘中,但是不方便管理和维护,因...
  • Biexiansheng
  • Biexiansheng
  • 2017-09-08 15:17:23
  • 384

Hadoop集群中启动namenode失败的解决办法

本hadoop集群规划为2台机器做namenode:       最近遇到了一个问题,执行start-dfs.sh的时候,在第一台机器上JPS发现namenode已经启动,可第二台的nameno...
  • liuyuliuyu520
  • liuyuliuyu520
  • 2015-06-08 11:06:06
  • 1018

NameNode、SecendNameNode和DataNode的工作机制

NameNode 保存元数据MetaData,fsimage(磁盘元数据副本),edits(日志)。当NameNode启动后,会将磁盘上的数据fsimage同步一份到内存中,同时DataNode启动会...
  • oppoppoppo
  • oppoppoppo
  • 2017-05-11 17:23:30
  • 215

Hadoop中SecondaryNameNode工作机制

首先来看一下HDFS的结构,如下图: 如上图,在HDFS架构中,NameNode是职责是管理元数据信息,DataNode的职责是负责数据存储,那么SecondaryNameNode的作用是什...
  • lzm1340458776
  • lzm1340458776
  • 2015-01-04 20:19:17
  • 1543

Namenode HA原理以及配置

NameNode HA 原理 • hadoop2.x之后,Clouera提出了QJM/Qurom Journal Manager. 这是一个基于Paxos算法实现的HDFS HA方案,它给出了一种较好...
  • jiajiren11
  • jiajiren11
  • 2017-12-10 21:04:27
  • 65

王家林的“云计算分布式大数据Hadoop第九讲Hadoop图文训练课程:剖析NameNode和Secondary NameNode的工作机制和流程.

  • 2013年06月19日 23:51
  • 43KB
  • 下载

集群启动使用Hadoop,运行后没有NameNode节点

集群启动Hadoop后,运行后有SecondNameNode和dataNode,但是没有NameNode节点?解决方法:1、先运行stop-all.sh 2、运行hadoop namenode -f...
  • u012500868
  • u012500868
  • 2017-10-05 21:33:55
  • 271

Hadoop学习(三)— hdfs : NameNode与DataNode的实现机制

一、NameNode的工作机制 二、DataNode的工作机制 三、HDFS在Java客户端编写
  • Tracker_wjw
  • Tracker_wjw
  • 2016-04-25 20:49:16
  • 2368
    个人资料
    持之以恒
    等级:
    访问量: 461
    积分: 241
    排名: 31万+
    文章存档