一、dits和fsimage
首先要提到两个文件edits和fsimage,下面来说说他们是做什么的。
那么问题来了,只有在名称节点(NameNode)启动的时候才会合并fsimage和edits,那么久而久之edits文件会越来越大,特别是大型繁忙的HDFS集群。这种情况下,由于某种原因你要重启名称节点(NameNode),那么会花费很长的时间去合并fsimge和edits,然后HDFS才能运行。
二、Secondary NameNode
目前使用的版本hadoop-0.20.2可以使用Secondary NameNode来解决上面的问题。Secondary NameNode定期合并fsimage和edits日志,把edits日志文件大小控制在一个限度下。因为内存需求和NameNode差不多(On the same order),所以Sencondary NameNode通常要运行在另外个机器上。
secondary NameNode配置在conf/masters文件,启动命令:bin/start-dfs.sh(如果你使用不建议的start-all.sh也是会启动的)。
三、什么时候checkpiont
secondary NameNode 什么时候执行checkpoint来合并fsimage和eidts。呢?有两个配置参数控制:
secondary NameNode 保存最后一次checkpoint的结果,存储结构和主节点(NameNode)的一样,所以主节点(NameNode)可以随时来读取。
如果你没有启动secondary NameNode 那么可以试试 bin/hadoop secondarynamenode -checkpoint 甚至 bin/hadoop secondarynamenode -checkpoint force. 看看生成的文件。
checkpoint可以解决重启NameNode时间过长的弊端。另外还有偏方:
四、Import Checkpoint(恢复数据)
如果主节点挂掉了,硬盘数据需要时间恢复或者不能恢复了,现在又想立刻恢复HDFS,这个时候就可以import checkpoint。步骤如下:
这样NameNode会读取checkpoint文件,保存到dfs.name.dir。但是如果你的dfs.name.dir包含合法的fsimage,是会执行失败的。因为NameNode会检查fs.checkpoint.dir目录下镜像的一致性,但是不会去改动它。
值得推荐的是,你要注意备份你的dfs.name.dir和 ${hadoop.tmp.dir}/dfs/namesecondary。
五、Checkpoint Node 和 Backup Node
在后续版本中hadoop-0.21.0,还提供了另外的方法来做checkpoint:Checkpoint Node 和 Backup Node。则两种方式要比secondary NameNode好很多。所以 The Secondary NameNode has been deprecated. Instead, consider using the Checkpoint Node or Backup Node.
Checkpoint Node像是secondary NameNode的改进替代版,Backup Node提供更大的便利,这里就不再介绍了。
增加
<property> <name>fs.checkpoint.period</name> <value>3600</value> <description>The number of seconds between two periodic checkpoints. </description> </property> <property> <name>fs.checkpoint.size</name> <value>67108864</value> <description>The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs.checkpoint.period hasn't expired. </description> </property> <property> <name>fs.checkpoint.dir</name> <value>/data/work/hdfs/namesecondary</value> <description>Determines where on the local filesystem the DFS secondary name node should store the temporary images to merge. If this is a comma-delimited list of directories then the image is replicated in all of the directories for redundancy. </description> </property>
fs.checkpoint.period表示多长时间记录一次hdfs的镜像。默认是1小时。
fs.checkpoint.size表示一次记录多大的size,默认64M
增加
<property> <name>dfs.http.address</name> <value>master:50070</value> <description> The address and the base port where the dfs namenode web ui will listen on. If the port is 0 then the server will start on a free port. </description> </property>
0.0.0.0改为namenode的IP地址
登录secondarynamenode所在的机器,输入jps查看secondarynamenode进程
进入secondarynamenode的目录/data/work/hdfs/namesecondary
正确的结果:
如果没有,请耐心等待,只有到了设置的checkpoint的时间或者大小,才会生成。
制造namenode宕机的情况
1) kill 掉namenode的进程
[root@master name]# jps 11749 NameNode 12339 Jps 11905 JobTracker [root@master name]# kill 11749
2)删除dfs.name.dir所指向的文件夹,这里是/data/work/hdfs/name
[root@master name]# rm -rf *
删除name目录下的所有内容,但是必须保证name这个目录是存在的
3)从secondarynamenode远程拷贝namesecondary文件到namenode的namesecondary
[root@master hdfs]# scp -r slave-001:/data/work/hdfs/namesecondary/ ./
4)启动namenode
[root@master /data]# hadoop namenode –importCheckpoint
正常启动以后,屏幕上会显示很多log,这个时候namenode就可以正常访问了
5)检查
使用hadoop fsck /user命令检查文件Block的完整性
hadoop fsck /
6)停止namenode,使用crrl+C或者会话结束
7)删除namesecondary目录下的文件(保存干净)
[root@master namesecondary]# rm -rf *
8)正式启动namenode
[root@master bin]# ./hadoop-daemon.sh start namenode
恢复工作完成,检查hdfs的数据
9)balancer
在使用start-balancer.sh时,
默认使用1M/S(1048576)的速度移动数据(so slowly...)
修改hdfs-site.xml配置,这里我们使用的是20m/S
<property> <name>dfs.balance.bandwidthPerSec</name> <value>20971520</value> <description> Specifies the maximum bandwidth that each datanode can utilize for the balancing purpose in term of the number of bytes per second. </description> </property>
然后结果是导致job运行变得不稳定,出现一些意外的长map单元,某些reduce时间处理变长(整个集群负载满满的情况下,外加20m/s的balance),据说淘宝的为10m/s,需要调整后实验,看看情况如何。
hadoop balancer -threshold 5