无法启动,namenode无法启动

NameNode运转进程详细剖析

近期境遇了两个标题,实施start-all.sh的时候发掘JPS一下namenode未有运转

Hadoop 不恐怕运维namenode

NameNode中多少个至关心重视要的数据结构

历次开机都得重新格式化一下namenode才可以

关闭hadoop后

FSImage

Namenode会将HDFS的文书和目录元数据存款和储蓄在三个叫fsimage的二进制文件中,每回保存fsimage之后到下一次封存之间的有所hdfs操作,将会记录在editlog文件中,当editlog到达一定的尺寸(bytes,由fs.checkpoint.size参数定义卡塔尔国或从上次封存过后势必时间段过后(sec,由fs.checkpoint.period参数定义卡塔尔国,namenode会重新将内部存款和储蓄器中对总体HDFS的目录树和文书元数据刷到fsimage文件中。Namenode便是通过这种方法来确定保障HDFS桐月数据音讯的安全性。

Fsimage是一个二进制文件,个中记录了HDFS中持有文件和目录的元数据消息,在作者的Hadoop的HDFS版中,该公文的中保留文件和目录的格式如下:

图片 1

 

当namenode重启加载fsimage时,就是遵照如下格式契约从文件流中加载元数据消息。从fsimag的积攒格式能够看见,fsimage保存犹如下音信:

1.        
首先是二个image
head,此中含有:

无法启动,namenode无法启动。a)         imgVersion(int):当前image的版本音信

b)        namespaceID(int):用来承保其他HDFS
instance中的datanode不会误连上圈套前NN。

c)         numFiles(long):整个文件系统中包含有稍许文件和目录

d)        genStamp(long):生成该image时的时刻戳音讯。

2.        
接下去正是对各样文件或目录的源数据音讯,假设是目录,则含有以下新闻:

a)         path(String):该目录的路线,如”/user/build/build-index”

b)        replications(short):别本数(目录即使从未别本,但此间记录的目录副本数也为3卡塔 尔(阿拉伯语:قطر‎

c)         mtime(long):该目录的修改时间的年月戳音讯

d)        atime(long):该目录的访问时间的时刻戳新闻

e)         blocksize(long):目录的blocksize都为0

f)         numBlocks(int):实际有个别许个公文块,目录的该值都为-1,表示该item为目录

g)        nsQuota(long):namespace
Quota值,若没加Quota限定则为-1

h)        dsQuota(long):disk
Quota值,若没加约束则也为-1

i)          username(String):该目录的所属客商名

j)          group(String):该目录的所属组

k)        permission(short):该目录的permission音信,如644等,有叁个short来记录。

3.        
若从fsimage中读到的item是叁个文书,则还有恐怕会附加包罗如下消息:

a)         blockid(long):归于该公文的block的blockid,

b)        numBytes(long):该block的大小

c)         genStamp(long):该block的光阴戳

当该文件对应的numBlocks数不为1,而是大于1时,表示该公文对相应三个block新闻,那个时候紧接在该fsimage之后的就能够有三个blockid,numBytes和genStamp新闻。

故而,在namenode运转时,就须求对fsimage依照如下格式进行各个的加载,以将fsimage中著录的HDFS元数据音信加载到内部存款和储蓄器中。

实际难题就出在tmp文件,默许的tmp文件每一回重复开时机被清空,与此同偶尔间namenode的格式化音讯就能够放任

在bin下执行

BlockMap

从上述fsimage中加载如namenode内部存款和储蓄器中的音讯中得以很明朗的看来,在fsimage中,并从未记录每三个block对应到哪几个datanodes的对应表音信,而只是储存了全部的关于namespace的相干音信。而真的各样block对应到datanodes列表的音信在hadoop中并未开展持久化存款和储蓄,而是在富有datanode运营时,各样datanode对本土磁盘进行围观,将本datanode上保存的block新闻举报给namenode,namenode在收取到每一个datanode的块消息上报后,将收受到的块消息,以至其所在的datanode音信等保存在内部存款和储蓄器中。HDFS就是通过这种块音信反映的办法来实现 block ->
datanodes list的对应表营造。Datanode向namenode陈说块新闻的长河叫做blockReport,而namenode将block ->
datanodes list的对应表消息保存在一个叫BlocksMap的数据结构中。

BlocksMap的内部数据结构如下:   

图片 2              

 

如上航海用体育场合展现,BlocksMap实际上正是一个Block对象对BlockInfo对象的三个Map表,在那之中Block对象中只记录了blockid,block大小以至时光戳新闻,这个音讯在fsimage中都有记录。而BlockInfo是从Block对象世袭而来,由此除了Block对象中保存的音信外,还包罗代表该block所属的HDFS文件的INodeFile对象援用以至该block所属datanodes列表的新闻(即上航海用体育地方中的DN1,DN2,DN3,该数额结构会在下文详述卡塔尔。

于是在namenode运维并加载fsimage达成之后,实际上BlocksMap中的key,也正是Block对象皆已加载到BlocksMap中,每种key对应的value(BlockInfo)中,除了代表其所属的datanodes列表的数组为空外,别的音讯也都早就打响加载。所以能够说:fsimage加载达成后,BlocksMap中仅缺乏各种块对应到其所属的datanodes
list的应和关系新闻。所缺这几个新闻,正是通过上文提到的从各datanode接纳blockReport来塑造。当全体的datanode陈述给namenode的blockReport管理完成后,BlocksMap整个结构也就构建实现。

于是乎我们得重新配置一个tmp文件目录

./hadoop namenode -format

BlockMap中datanode列表数据结构

在BlockInfo中,将该block所属的datanodes列表保存在贰个Object[]数组中,但该数组不止保存了datanodes列表,还隐含了额外的音讯。实际上该数组保存了之类新闻:

图片 3

 

上海图书馆表示贰个block满含有三个别本,分别放置在DN1,DN2和DN3四个datanode上,每一种datanode对应三个安慕希组,该安慕希组中的第一个要素,即上航海用体育场面中prev
block所指的是该block在该datanode上的前四个BlockInfo援用。第多少个因素,约等于上海教室中next
Block所指的是该block在该datanode上的下一个BlockInfo援引。每一种block有稍许个别本,其相应的BlockInfo对象中就能够有稍微个这种安慕希组。

       Namenode选择这种结构来保存block->datanode
list的意在节省namenode内部存款和储蓄器。由于namenode将block->datanodes的附和关系保留在了内部存款和储蓄器个中,随着HDFS中文件数的加多,block数也会相应的扩大,namenode为了保存block->datanodes的音信已经消耗了风华正茂对风流倜傥多的内部存款和储蓄器,假若还像这种措施相像的保存datanode->block
list的对应表,势必开销越来越多的内部存款和储蓄器,何况在骨子里行使中,要查一个datanode上保留的block
list的利用实际上相当少,超越20%状态下是要依附block来查datanode列表,所以namenode中经过上海体育场所的措施来保存block->datanode
list的照看关系,当需求查询datanode->block
list的应和关系时,只供给沿着该数据结构中next
Block的针对性关系,就能够得出结果,而又不供给保存datanode->block
list在内部存款和储蓄器中。

图片 4

先是在home目录下创立贰个Hadoop_tmp目录

重启

sudo mkdir ~/hadoop_tmp

ok

接下来改善hadoop/conf目录里面包车型客车core-site.xml文件,出席以下节点:

更加多Hadoop相关音信见Hadoop
专项论题页面
http://www.linuxidc.com/topicnews.aspx?tid=13

相关文章