不多说,直接上干货!
HDFS升级和回滚机制
作为一个大型的分布式系统,Hadoop内部实现了一套升级机制,当在一个集群上升级Hadoop时,像其他的软件升级一样,可能会有新的bug或一些会影响现有应用的非兼容性变更出现。在任何有实际意义的HDFS系统中,丢失数据是不允许的,更不用说重新搭建启动HDFS了。当然,升级可能成功,也可能失败。如果失败了,那就用rollback进行回滚;如果过了一段时间,系统运行正常,那就可以通过finalize正式提交这次升级。
相关升级和回滚命令如下:
bin/hadoop namenode一upgrade //升级
bin/hadoop namenode一rollback //回滚
bin/hadoop namenode一finalize //提交
bin/hadoop namenode一importCheckpoint //从Checkpoint恢复
上述命令的importCheckpoint参数用于NameNode发生故障后,从某个检查点恢复。HDFS允许管理员退回到之前的Hadoop版木,将集群的状态回滚到升级之前。
在升级之前,管理员需要用以下命令删除已存在的备份文件:
bin/hadoop dfsadmin-finalizeUpgrade //升级终结操作
下面简单介绍一下一般的升级过程。
在升级Hadoop软件之前,检查是否已经存在一个备份,如果备份存在,可执行升级终结操作删除这个备份。通过以下命令能够知道是否需要对一个集群执行升级终结操作:
dfsadmin -upgradeProgress status
1) 停止集群并部署Hadoop的新版本。
2) 使用upgrade选项运行新的版本(bin/start-dfs.sh -upgrade)
在大多数情况下,集群都能够正常运行。一旦我们认为新的HDFS运行正常(也许经过几天的操作之后),就可以对其执行升级终结操作。需要注意的是,在对一个集群执行升级终结操作之前,删除那些升级前就已经存在的文件并不会真正地释放DataNode上的磁盘空间。
如果需要退回到老版本,执行步骤如下:
1) 停止集群并部署Hadoop的老版本。
2) 用回滚选项启动集群,命令如下:
bin/start-dfs.h -rolback
上面介绍了HDFS的升级和回滚的基本机制,其实可以从状态转移的角度来理解理解HDFS的升级和回滚机制。整个HDFS的状态有:Normal, Upgraded, Rollbacking, Upgrading,Finalizing五种,HDFS集群的状态转移示意图,如下图所示。
从上图可以看出,升级、回滚、提交都不可能一下完成,这也就是说,在HDFS系统出现故障时,集群可能处于上图右侧图中某一个状态中,特别是在分布式的各个节点上,甚至可能出现有些节点已经升级成功,但有些节点可能处干中间状态的情况,所以Hadoop采用类似于数据库事务的升级机制也就很容易理解了。
同时,大家可以关注我的个人博客:
http://www.cnblogs.com/zlslch/ 和 http://www.cnblogs.com/lchzls/ http://www.cnblogs.com/sunnyDream/
详情请见:http://www.cnblogs.com/zlslch/p/7473861.html
人生苦短,我愿分享。本公众号将秉持活到老学到老学习无休止的交流分享开源精神,汇聚于互联网和个人学习工作的精华干货知识,一切来于互联网,反馈回互联网。
目前研究领域:大数据、机器学习、深度学习、人工智能、数据挖掘、数据分析。 语言涉及:Java、Scala、Python、Shell、Linux等 。同时还涉及平常所使用的手机、电脑和互联网上的使用技巧、问题和实用软件。 只要你一直关注和呆在群里,每天必须有收获
对应本平台的讨论和答疑QQ群:大数据和人工智能躺过的坑(总群)(161156071)