加入收藏 | 设为首页 | 会员中心 | 我要投稿 | RSS
您当前的位置:首页 > 教程文章 > NOSQL数据库

Hadoop源代码分析(36)

时间:2012-04-27 00:33:46  来源:  作者:

 

转战进入Secondary NameNode,前面的分析我们有事也把它称为从NameNode,从NameNode在HDFS里是个小配角。
Secondary NameNode有关系的类不是很多,如下图:


首先要讨论的是NameNode和Secondary NameNode间的通信。NameNode上实现了接口NamenodeProtocol(如下图),就是用于NameNode和Secondary NameNode间的命令通信。
NameNode和Secondary NameNode间数据的通信,使用的是HTTP协议,HTTP的容器用的是jetty,TransferFsImage是文件传输的辅助类。


 
GetImageServlet的doGet方法目前支持取FSImage(getimage),取日志(getedit)和存FSImage(putimage)。例如:
可以获取FSImage。
可以获取日志文件。
保存FSImage需要更多的参数,它的流程很好玩,Secondary NameNode发送一个HTTP请求到NameNode,启动NameNode上一个HTTP客户端到Secondary NameNode上去下载FSImage,下载需要的一些信息,都放在从NameNode的HTTP请求中。
我们先来考察Secondary NameNode持久化保存的信息:
[hadoop@localhost namesecondary]$ ls –R
.:
current image in_use.lock previous.checkpoint

./current:
edits fsimage fstime VERSION

./image:
fsimage

./previous.checkpoint:
edits fsimage fstime VERSION
in_use.lock的用法和前面NameNode,DataNode的是一样的。对比NameNode保存的信息,我们可以发现Secondary NameNode上保存多了一个previous.checkpoint。CheckpointStorage就是应用于Secondary NameNode的存储类,它继承自FSImage,只添加了很少的方法。
previous.checkpoint目录保存了上一个checkpoint的信息(current里的永远是最新的),临时目录用于创建新checkpoint,成功后,老的checkpoint保存在previous.checkpoint目录中。状态图如下(基类FSImage用的是黑色):


 
至于上面目录下文件的内容,和FSImage是一样的。
CheckpointStorage除了上面图中的startCheckpoint和endCheckpoint方法(上图给出了正常流程),还有:
void recoverCreate(Collection<File> dataDirs,
Collection<File> editsDirs) throws IOException
FSImage.coverTransitionRead类似,用于分析现有目录,创建目录(如果不存在)并从可能的错误中恢复。
private void doMerge(CheckpointSignature sig) throws IOException
doMerge被类SecondaryNameNode的同名方法调用,我们后面再分析。
来顶一下
返回首页
返回首页
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
推荐资讯
在CentOS下搭建Android 开发环境
在CentOS下搭建Androi
轻松搭建属于自己的Ubuntu发行版
轻松搭建属于自己的Ub
利用SUSE Studio 打造自己的个性化Linux发行版
利用SUSE Studio 打造
那些采用PHP技术的IT大企业
那些采用PHP技术的IT大
相关文章
    无相关信息
栏目更新
栏目热门