概述
我们是采用的纯本地升级方案,所以无需开启外网(本身也非常非常不建议开外网,因为Hadoop没有配置任何的攻击防御能力)
这里我是从5.4.4版本升级到最新的5.7.1。升级途中还算一路顺分,但也少不了坎坎坷坷的事情。这里一一列举下。
一、Cloudera提供的两种升级方案
- 全自动升级
- 也就是说所有的依赖啥的都由Cloudera帮你处理好即可,我们不需要中途再去每个服务手动升级了
- 手动升级
- 按照Cloudera官方的说法是有部分服务需要你手动选择升级,其实就是除了Zookeeper、HDFS、YARN以外的所有服务都需要你手动执行升级才能完成
- 当然,建议是全部都采用统一的CDH包,不要一部分是高版本一部分是低版本这样可能因为CM针对CDH的参数配置不同从而引发出一系列血案
二、CM和CDH区别
这里需要说明下,Cloudera提供的Hadoop全套解决方案大致分为CM和CDH。
- CM:负责集群机器的管理监控,以及对CDH的管理
- CDH:一套由Cloudera负责打包好的parcel包,里面含有大部分的Apache Hadoop服务,但是也有的是被阉割过的(例如Spark),以及部分服务是不支持的(社区众多,没法全支持。例如Elasticsearch)
对于升级
对于升级而言CM和CDH需要分开升级的,必须先升级CM再升级CDH,而且CM对应的版本号一定要大于等于CDH的版本号。
三、CM升级
整个流程是采用repo源的方式升级
- 首先需要配置好repo源,整个集群能够访问即可
- 然后参照官方文档安装相关的yum包,这里需要在每个节点都安装(几十台机器写个shell分发即可)
- 检查主节点的YUM源是否已经有了新版本
- 备份元数据(我们用的是MySQL,直接mysqldump即可)
- 用YUM升级manager节点的全部服务(server,demaon,agent)
- 然后启动全部集群通过web界面配置本地的repo源地址进行安装
- 这里我们只需要升级好manager节点其他节点会自动升级
- 对于JDK,这里选择性升级即可,我们已经是1.7了所以暂时不用升级
四、CDH升级
这里整个升级也是采用本地parcel包的方式升级。
前提
- 现在已有集群上面配置好parcel源,并且进行分发
- 检查并配置好JDBC,这里的JDBC需要安装官方的说法配置在/usr/share/java/下面。因为这块CDH并不会帮你处理好配置
- 做好备份以备正常恢复(MySQL元数据,NameNode)
注意事项
- 自动升级失败:我们根据错误提示解决故障,然后对剩下的服务逐个进行升级
- 如果涉及到Hive自定义的UDF需要根据升级至的版本重新打包编译然后再升级后将Hive server2及其有客户端的exec包替换掉。
- 对于Hive Metastore如果我们升级后启用了HDFS HA特性这里必须升级,否则不要升级。
- 这里需要多说点,CDH对于Hive Metastore的升级(其实就是更新hive表的指向路径)很傻,是一条一条记录去做update的,我们这里完全可以自己手动的去批量更新HDFS的nameserver地址。在没有启用HA时候是hostname:8020,而启用了HA时候是nameserver:8020