问题场景
1、集群启动后,可以查看文件,但是上传文件时报错,打开web页面可看到namenode正处于safemode状态,怎么处理?
2、Namenode服务器的磁盘故障导致namenode宕机,如何挽救集群及数据?
3、Namenode是否可以有多个?namenode内存要配置多大?namenode跟集群数据存储能力有关系吗?
4、文件的blocksize究竟调大好还是调小好?
……
诸如此类问题的回答,都需要基于对namenode自身的工作原理的深刻理解。
NAMENODE职责
1.负责客户端请求的响应
2.元数据的管理(查询,修改)
元数据管理
namenode对数据的管理采用了三种存储形式:
- 内存元数据(NameSystem)
- 磁盘元数据镜像文件
- 数据操作日志文件(可通过日志运算出元数据)
存储机制:
A.内存中有一份完整的元数据(内存meta data) B.磁盘有一个“准完整”的元数据镜像(fsimage)文件(在namenode的工作目录中) C.用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件)
元数据手动查看:
可以通过hdfs的一个工具来查看edits中的信息
bin/hdfs oev -i edits -o edits.xml bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml
元数据的checkpoint:
每隔一段时间,会由secondary namenode
将namenode
上积累的所有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的附带作用:
namenode和secondary namenode的工作目录存储结构完全相同,所以,当namenode故障退出需要重新恢复时,可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录,以恢复namenode的元数据。