Hadoop- NameNode和Secondary NameNode元数据管理机制

 

元数据的存储机制

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

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

C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件)

NameNode和Secondary NameNode元数据管理机制

客户端每次对文件的操作,如果涉及到元数据的更新(读除外),比如说更改文件的名称,路径,移动,复制,上传,删除等,除了查之外,其他增删改都会有可能涉及到与元数据的更改。dfs不支持客户端更改文件内容,只能在文件后面追加。

注:当客户端对hdfs中的文件进行新增或者修改操作,操作记录首先被记入edits日志文件中,当客户端操作成功后,相应的元数据会更新到内存meta.data中。当日志里面累积的操作记录越来越多,与老的fsimage相差越来越大,这时候需要由Secondary NameNode定期把edits文件和老的fsimage做一个合并上传上NameNode替换掉老的fsimage,这时候NameNode上的fsimage文件和内存上的元数据永远保持在一个小的差距里面。NameNode工作时,它的元数据查询都是找内存的,不会去找fsimage,也不会去找edits。

XML处理器输出 fsimage 的 xml 文档,包含了 fsimage 中的所有信息,比如 inodeid 等。该处理器的输出支持XML工具的自动化处理和分析,由于XML语法格式的冗余,该处理器的输出也最大。实例如下:

[root@srv02 ]# hdfs oiv -i fsimage 0000000000000000000116 -p XML -o fsimage.xml
[root@srv02 ]# cat fsimage.xml

edits文件是操作记录文件,也可以查看个究竟:

1

hdfs oev -i edits edits_0000000000000013356-0000000000000013357  -o edits.xml

 

人已赞赏
0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
有新消息 消息中心
搜索