hadoop摘抄（四）

五、 在Hadoop集群实施成功后，再次格式化名称节点，请问此时datanode还能加入集群不？如果不能加入怎样解决？模拟过程并抓图 

1. 停止集群，并bin/hadoop namenode -format

 

2. 启动集群，并查看datanode

 

datanode 无法启动

3. 查看日志，显示 datanode 与 namenode namespaceID 不同所致

 

4. 修改所有datanode /usr/local/hadoop/tmp/dfs/data/current/VERSION 中namespaceID 为 namenode namespaceID，或删除datanode 中 /usr/local/hadoop/tmp/dfs/data 目录。这里采用后者。

 

5. 重启集群，datanode 启动

 

六、 怎样控制namenode检查点发生的频率，用实验模拟检查点发生的前后过程，并抓图发生前和发生后的元数据情况进行比较，说明之

1. core-site.xml 中设置 fs.checkpoint.period=180, scp 到 所有节点

 

2. 重启集群，并查看namenode /usr/local/hadoop/tmp/dfs/name/current中 fsimage,edits等的更新频率。

每隔4分钟查看，发现namenode 每隔 180 秒 checkpoint 更新
 

3. 观察checkpoint 前后 namenode的变化

检查点发生前：
（1）16:10 的checkpoint 显示，namenode的fsimage和edits 最后修改时间为16：10。
（2）16：11 向hdfs系统加入 input ，namenode 中的edits 记录 这次操作，其修改时间为16：11 
检查点发生后（16：13）：namenode 中的fsimage（16：10） 被 seondarynamenode 新产生的fsimage（16：13-由fsimage16：10 和 edits 16：11合成）代替，edits（16：11）被新产生的edits代替。
 

2013-8-9 22:59 上传

下载附件 (622.6 KB)

4.  基本原理

当距离上个checkpoint 时间 为${fs.checkpoint.period} 时：

1. 次（secondary）名称节点请求名称节点滚动edits文件，使新的edits log 放到另一个新生成的edits文件。
2. 次名称节点 通过 HTTP GET 获取名称节点的fsimage和edits文件
3. 次名称节点将fsimage文件载入 内存，并应用edits 文件中的每一项操作，这样就创建了一个新的合成的fsimage 文件。
4. 次名称节点采用 HTTP POST 方式 将刚合成的fsimage 发送回 名称节点
5. 名称节点用刚从次名称节点收到的fsimage代替老一版本的fsimage, 并用第一步中产生的edits 代替原先的edits，同时将fctime文件更新到checkpoint发生的时间

最终，名称节点就有了一份最新的fsimage文件和一个更短的edits文件（该edits文件不一定空，当次名称节点在执行checkpoint操作时，edits 可能已经记录下了一些hdfs系统的操作）

2013-8-9 22:59 上传

下载附件 (620.54 KB)