Hadoop集群中,NameNode节点存储着HDFS上所有文件和目录的元数据信息
如果NameNode挂了,也就意味着整个Hadoop集群也就完了
所以,NameNode节点的备份很重要,可以从以下2个方面来备份NameNode节点
1. 在hdfs-site.xml中,配置多个name的dir到不同的磁盘分区上:
<property>
<name>dfs.name.dir</name>
<value>/pvdata/hadoopdata/name/,/opt/hadoopdata/name/</value>
</property>
2. 在另外的一台服务器上配置Secondary NameNode:它是NameNode的一个备份
Secondary NameNode会定期合并fsimage和edits日志,将edits日志文件大小控制在一个限度下
合并的时机是由2个配置参数决定的:
fs.checkpoint.period,指定连续两次检查点的最大时间间隔, 默认值是1小时。
fs.checkpoint.size定义了edits日志文件的最大值,一旦超过这个值会导致强制执行检查点(即使没到检查点的最大时间间隔)。默认值是64MB。
Secondary NameNode的配置过程如下:
- 在conf/masters中指定第二名称节点的主机名
- 在core-site.xml中指定checkpoint的目录
<property>
<name>fs.checkpoint.dir</name>
<value>/opt/hadoopdata/secondname,/pvdata/hadoopdata/secondname</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>
如果NameNode节点挂了,可以按照如下步骤来从Secondary NameNode来恢复:
- 在dfs.name.dir指定的位置建立一个空文件夹
- 从Secondary NameNode上把secondname的目录给scp到新的NameNode机器的fs.checkpoint.dir下
- 使用hadoop/bin/hadoop namenode -importCheckpoint来启动NameNode,主要不要执行format命令
- 使用hadoop fsck /user命令检查文件Block的完整性
详细的Secondary NameNode细节可参考Hadoop官方文档:
http://hadoop.apache.org/common/docs/r0.20.2/hdfs_user_guide.html#Secondary+NameNode
==========================================================
惊天大悲剧-Hadoop的rmr和trash
这两天在操作Hadoop集群时,由于一个误操作,制作了一个天大的悲剧
不小心把Hadoop集群上的所有文件全部删除了,具体情况是这样的:
我用hadoop的超级帐户要建立一个目录,结果发现位置错了
也是,想使用rmr删掉那个目录,可是不小心把命令写成了
hadoop fs -rmr /user
于是,悲剧出现了,所有user目录下的所有目录和文件全都没有了
当时我就慌神了,赶紧从web查看50070的服务
眼看着DFS Used空间从100多G不停的减少
后来才反应过来,赶紧停掉namenode节点,然后上网google办法
后来,从secondname节点重新恢复了一个checkpoint
但绝大部分数据都已经丢失了,只恢复了一小部分数据,已经没啥用了
幸好,原始log我们在其它服务器上还保留的有,只能重新分析再入Hadoop了
总结了一下几点教训:
- 首先一定要控制好hadoop上各用户的权限,使各user只能操作自己的目录
- 尽量少用hadoop的超级用户进行操作,可以减少误操作
- hadoop的rm和rmr命令,设计的太BT了,连一个确认提示都没有,直接就删除了。看到有人给官方提了这个建议,但人家回复说:已经有了trash机制了,所以不需要提示,真是无语….
- hadoop的trash功能:很遗憾,之前没有配置trash,所以就直接给删除了,经过这次误操作,赶紧配置上trash,并设置保留时间为7天。
在core-site.xml中增加如下配置,表明rm后会在trash中保留多少分钟:
<property>
<name>fs.trash.interval</name>
<value>10080</value>
<description>
Number of minutes between trash checkpoints. If zero, the trash feature is disabled
</description>
</property>
很遗憾的是,hadoop的这个默认值是0,就是直接删除了,为什么要这么设计呢?郁闷….
经过简单的测试,这个trash功能还是不错的,当rm后,它会move到当前文件夹下的.Trash目录下
如果你删除一个文件或目录多次,则hadoop会自动在name后加上数字序列号
这样,如果你误删除后,就可以有选择的恢复文件了
标签:fs,备份,hadoop,Hadoop,user,oplog,NameNode,trash From: https://blog.51cto.com/u_16255870/7535844hadoop fs -mkdir /user/oplog/test
hadoop fs -put *.txt /user/oplog/test
hadoop fs -rmr /user/oplog/test
hadoop fs -ls /user/oplog/.Trash/Current/user/oplog
drwxr-xr-x – oplog oplog 0 2010-11-16 10:44 /user/oplog/.Trash/Current/user/oplog/test
hadoop fs -mv /user/oplog/.Trash/Current/user/oplog/test /user/oplog/
hadoop fs -ls /user/oplog/.Trash/Current/user/oplog
drwxr-xr-x – oplog oplog 0 2010-11-16 10:44 /user/oplog/.Trash/Current/user/oplog/test
drwxr-xr-x – oplog oplog 0 2010-11-16 10:47 /user/oplog/.Trash/Current/user/oplog/test.1