记一次简单的hdfs备份恢复过程

最新推荐文章于 2026-05-19 05:42:46 发布

原创最新推荐文章于 2026-05-19 05:42:46 发布 · 5.5k 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#hadoop #namenode

在长时间未使用的Hadoop集群重启时，遇到无法连接HDFS的问题，由于namenode启动时GC问题导致编辑日志重放失败。通过调整GC参数，成功重启namenode，但恢复过程缓慢。手动备份HDFS并尝试生成新的fsimage时，出现不一致的检查点错误，解决方法是删除hadoop.tmp.dir目录。参考Hortonworks社区的检查点指南完成修复。

集群有段时间没人用了，重新启动时遇到无法连接到hdfs问题

jps查看命令之后发现是namenode没有启动起来，查看hdfs的日志：

找到问题的原因了，在namenode启动过程中重放hdfs的edit log时爆掉了GC，Google了一下，发现可以修改GC参数：

export HADOOP_OPTS="-XX:-UseGCOverheadLimit

重启启动namenode成功（中间恢复过程很慢很慢，跑到第二天早上，恢复失败。。。再次启动namenode又恢复成功了。。。还没明白原因。。）

感觉hdfs的edit log重放过程会有点慢，去找了一下命令，可以手动备份hdfs，生成新的fsimage，命令如下：

在namenode节点上存储工作空间：

hdfs dfsadmin -safemode enter  
hdfs dfsadmin -saveNamespace  
hdfs dfsadmin -safemode leave

在secondarynamenode上重新生成fsimage:

hadoop-deamon.sh stop secondarynamenode #关闭secondarynamenode
mv $HADOOP_HOME/tmp $HADOOP_HOME/tmp_bak # 备份 $hadoop.tmp.dir目录，即secondarynamenode文件存放位置
mkdir $HADOOP_HOME/tmp 
hadoop secondarynamenode -checkpoint force  #手动生成fsimage备份
hadoop-deamon.sh start secondarynamenode

直接运行fsimage备份命令会遇到问题：

ERROR namenode.SecondaryNameNode: checkpoint: Inconsistent checkpoint fields.

需要手动移除hadoop.tmp.dir目录即可

参考资料：

https://community.hortonworks.com/content/supportkb/49438/how-to-manually-checkpoint.html