hdfs 升级，cdh3 升级 cdh4

Step 1: 做下saveNamespace操作，停掉集群，并备份下 HDFS 的 Metadata

 1.1 让namenode进入safe mode状态
   $ bin/hadoop dfsadmin -safemode enter
 1.2 执行saveNamespace操作

   $ bin/hadoop dfsadmin -saveNamespace

 1.3 stop 集群 

 1.4 备份 dfs.name.dir 下面的元数据

 

Step 2: 下载 CDH4，把CDH3的配置拷过来

注意CDH3配置文件是在conf目录下面，CDH4的配置文件目录已经改成了etc/hadoop目录

 

Step 3: 升级 HDFS Metadata

3.1 进入CDH4目录下执行: 

sbin/hadoop-daemon.sh start namenode -upgrade -clusterid mycluster-test

说明mycluster-test是clusterid，可以指定，也可以不指定，如果不指定那么系统会自动生成一个

3.2 查看日志目录下的namenode日志,如果出现:

Upgrade of ${dfs.namenode.name.dir} is complete

说明元数据已经升级成功

3.3 启动DataNodes:

在每一台datanode上面启动datanode服务

sbin/hadoop-daemon.sh start datanode

datanode节点会自动升级

3.4 等待namenode退出安全模式,然后执行fsck

bin/hdfs fsck /

3.5 确认目录健康，没有block丢失后可以执行finalzeUpgrade及启动secondarynamenode

bin/hdfs dfsadmin -finalizeUpgrade

#finalized后将不能rollback

sbin/hadoop-daemon.sh start secondarynamenode

#请清理掉dfs.namenode.checkpoint.dir目录下老版本文件，否则会启动失败

 

回滚操作：

若在升级过程中出了问题，想回滚到cdh3版本，一定不能执行bin/hdfs dfsadmin -finalizeUpgrade。在执行finalizeUpgrade之前都可以回滚

 

在cdh3 版本下面执行

（1）回滚Namenode，在namenode机器上面执行

bin/hadoop-daemon.sh start namenode -rollback

（2）回滚DataNode，在namenode机器上面执行

bin/hadoop-daemons.sh start datanode -rollback

 

也可以手工操作，把数据move回来，然后正常启动

（1）回滚Namenode的数据

remove dfs.name.dir/current目录，mv dfs.name.dir/previous dfs.name.dir/current目录

这样子就恢复回namenode的元数据了

（2）回滚DataNode的数据

remove dfs.data.dir/current目录，mv dfs.data.dir/previous dfs.data.dir/current目录

这样子就恢复回datanode的数据了

操作完后就可以重新启动cdh3版本了

 

 

总的来说，升级是：mv current previous，创建current，读旧的元数据，写成新版本到current里面，而DataNode节点上面的block数据通过hardlink来放到current目录下面

                 回滚是：rm current，mv previous current

 

参考：

http://cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-Installation-Guide/cdh4ig_topic_6_3.html

注意第一步里面的saveNamespace操作最好做一下，因为在测试的时候就发生过从cdh3升级到cdh4，cdh3 fsck没有问题，cdh4就有个corrupt的block。查明原因是因为两个版本在处理上面的一些小区别：

查看NameNode日志发现：
（1）CDH4：
2013-08-27 17:22:05,157 INFO BlockStateChange: BLOCK NameSystem.addToCorruptReplicasMap: blk_2350489058707117631 added as corrupt on 10.232.133.200:50010 by 10.232.133.200 because block is COMPLETE and reported length 1570730 does not match length in block map 1570304

（2）CDH3：
2013-08-27 16:56:40,904 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Inconsistent size for block blk_2350489058707117631_115480 reported from 10.232.133.200:50010 current size is 1570304 reported size is 1570730

 

这里两个版本都说这个块datanode上面的大小和namenode记得的大小不同。
从代码上面来看，cdh3在处理的时候如果 datanode汇报上来的块大小如果比namenode记住的要大，那么不会把这个block设为corrupt的。
但是cdh4在处理的时候只要datanode汇报上来的块大小跟namenode上面的不一致，那么就会把这个块设为corrupt的。

 

在stop cdh3的时候做下saveNamespace，那么namenode就会更新block的大小到datanode上报的大小。