CDH CM版本 6.0.1 升级到 CM 6.2.0 当前最新版本（CentOS 7.x）

CDH 的 6.0.1 是一个尴尬的版本，那时候 cloudera 尚未将 spark 更新到 2.4 还使用的是 spark 2.2版本。 但后来咱们发现 2.3 | 2.4 更新了很是多的 feature 和修复了一些 bug 以及更新了不少包括 structed streaming 特性。而且最近最新的 6.2.0 将会在不久以后提供 Apache phoenix 的支持。因此我尝试将目前的 CDH 升级一下而且记录下来。

 

CM 升级：

1. 准备工做：

在进行 CDH minor 版本升级以前需先对 CM 进行升级，CM 对以前的版本向下兼容，好比 6.0.1 不能管理 6.0.1 之上的版本却能管理小于版本号 6.0.1 如下的版本。

follow 官方文档首先咱们经过 reference 的第一个连接进入到对 cm 升级准备页面。

而后经过相关命令查看目前主机以及 CM CDH 系统的状况，并将信息填入上面的 prepare my environment 中。下面的升级步骤都会 follow 这里选择的东西不要填错或者乱填

查看 Operating System 

lsb_release -a

查看目前 CM 使用的 metastore 状况

cat /etc/cloudera-scm-server/db.properties

 

新版本 JDK 支持状况

Cloudera Enterprise Version    Supported JDK
5.3 -5.15    Oracle JDK 1.7, Oracle JDK 1.8
5.16 and higher 5.x releases    Oracle JDK 1.7, Oracle JDK 1.8, OpenJDK 1.8
6.0    Oracle JDK 1.8
6.1    Oracle JDK 1.8, OpenJDK 1.8
6.2    Oracle JDK 1.8, OpenJDK 1.8

能够看到咱们使用的 6.2 版本依然支持 Oracle JDK1.8 因此这一部分咱们无需升级。从 6.1 开始 CM 开始支持 OpenJDK 1.8 ，这在以前是不支持的，并且会引起不少 agent 上面的问题。

若是非 Oraclejdk1.8 的同窗可能须要对此进行很是多的处理，下面的内容均跳过了从新安装 jdk 的步骤，若是须要参考更全面的信息请参阅官方文档。

 

下面就是作一些备份数据的工做，一般意义上来讲，若是咱们进行 major 版本的升级，这一步的工序应该很是多很是复杂，可是进行 minor 或者 maintaince 级别的升级相对来讲改动较少会稍微轻松一点，须要注意的地方没有那么多。可是该作的备份咱们仍是给作上，确保可回滚。

 

2. 备份相关监控和 scm 数据库组件：

备份 CMA(Cloudera Manager Agent)

建立一个方便使用的环境变量，而且建立备份日期的文件夹一枚

export CM_BACKUP_DIR="`date +%F`-CM6.0.1"
echo $CM_BACKUP_DIR
mkdir -p $CM_BACKUP_DIR

备份跟 CMA 相关的目录信息

sudo -E tar -cf $CM_BACKUP_DIR/cloudera-scm-agent.tar --exclude=*.sock /etc/cloudera-scm-agent /etc/default/cloudera-scm-agent /var/run/cloudera-scm-agent /var/lib/cloudera-scm-agent

备份安装仓库信息

sudo -E tar -cf $CM_BACKUP_DIR/repository.tar /etc/yum.repos.d

 

先去 admin 界面将 scm action 中止。正常中止全部服务。

而后对 scm 以及 scm agent 进行停机

sudo systemctl stop cloudera-scm-server
sudo systemctl stop cloudera-scm-agent

 

备份 CMS(Cloudera Management Service) 信息

备份 Service monitor 信息

sudo cp -rp /var/lib/cloudera-service-monitor /var/lib/cloudera-service-monitor-`date +%F`-CM6.0.1

备份 Host monitor 信息

sudo cp -rp /var/lib/cloudera-host-monitor /var/lib/cloudera-host-monitor-`date +%F`-CM6.0.1

备份 Event Server 信息

sudo cp -rp /var/lib/cloudera-scm-eventserver /var/lib/cloudera-scm-eventserver-`date +%F`-CM6.0.1

备份 cms 信息

sudo -E tar -cf $CM_BACKUP_DIR/cloudera-scm-server.tar /etc/cloudera-scm-server /etc/default/cloudera-scm-server

备份 scm 数据库信息

mysqldump --databases database_name --host=database_hostname --port=database_port -u user_name -p > $HOME/database_name-backup-`date +%F`-CM6.0.1.sql

 

3. 开始升级过程：

注意全部的升级过程期间最好保证 cm 是正常退出的状况包括 scm 和 cm-agent 是中止的状况。而且要保障期间不会有任何快照之类的 job 还在执行，不然可能致使升级以后 cm 起不来。

删除以前全部的 repo 设置

sudo rm /etc/yum.repos.d/cloudera*manager.repo*

添加咱们的 6.2.0 的仓库配置

[cloudera-manager]
# Packages for Cloudera Manager
name=Cloudera Manager
baseurl=https://archive.cloudera.com/cm6/6.2.0/redhat7/yum/
gpgkey=https://archive.cloudera.com/cm6/6.2.0/redhat7/yum/RPM-GPG-KEY-cloudera
gpgcheck=1

安装 jdk 的步骤咱们跳过，由于咱们已是 Oracle1.8 的 jdk 了。

更新 scm

sudo yum clean all
sudo yum upgrade cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent 

而后就是等待，由于若是是国内服务器，访问 cloudera 的服务可能速度比较慢，若是网速不行这里要等蛮久的 demons 有 1.1GB

建议速度不行能够用 proxychain 提早代理上再进行升级。升级完成后能够看到

[root@ryze-1 yum.repos.d]# rpm -qa 'cloudera-manager-*'
cloudera-manager-daemons-6.2.0-968826.el7.x86_64
cloudera-manager-server-6.2.0-968826.el7.x86_64
cloudera-manager-agent-6.2.0-968826.el7.x86_64

 

完成升级启动咱们的 agent 服务和 scm 服务

来到此界面，若是没能来到此界面能够参考日志进行一些排错

tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log
tail -f /var/log/cloudera-scm-agent/cloudera-scm-agent.log
tail -f /var/log/messages

 

4. 帮助其余机器升级 agent：

官方提供了两种方法进行安装。

1. 第一种是在上面展现的界面下面能够直接点一下，而后像以前安装包同样对其余机器进行一键安装。建议使用这个很方便，可是若是你网络不行就只能使用下面的方法2了。

2. 方法二就是按照上面的步骤手动对每一台机器的 agent 版本进行更新，我拿升级一台来作介绍，若是是相同的部署能够写脚本就行批量部署。

登录目标机器

删除以前的 repo 

sudo rm /etc/yum.repos.d/cloudera*manager.repo*

在目录 /etc/yum.repos.d 建立升级文件须要的 /etc/yum.repos.d/cloudera-manager.repo 信息

[cloudera-manager]
# Packages for Cloudera Manager
name=Cloudera Manager
baseurl=https://archive.cloudera.com/cm6/6.2.0/redhat7/yum/
gpgkey=https://archive.cloudera.com/cm6/6.2.0/redhat7/yum/RPM-GPG-KEY-cloudera
gpgcheck=1

中止机器上的 agent

sudo systemctl stop cloudera-scm-agent

更新 agent packages

sudo yum clean all
sudo yum repolist
sudo yum upgrade cloudera-manager-daemons cloudera-manager-agent 

安装完成

rpm -qa 'cloudera-manager-*'
cloudera-manager-agent-6.2.0-..cm...
cloudera-manager-daemons-6.2.0-..cm...

从新启动 agent 向 cm 上报信息

sudo systemctl start cloudera-scm-agent

 

无论采用那种办法，当 agent 所有升级完毕后，使用 Host Inspector 检测全部上报机器状况。

注意在安装包的过程可能出现某些主机失败，放心 cm 会对安装失败的软件包进行回滚，咱们能够等到全部都安装停下来以后刷新页面重试失败的便可。注意观察相关的日志，看是否错误是由于一些包冲突引发的，那些错误须要手动排除一下。

 

升级完成以后

进入 HOME PAGE 应该会看到不少配置上的修改，应该都是新版本 CM 对 DP 上的一些优化，从新部署相关客户端便可。

在完成了 CM 升级以后，将来几天我将会对 CDH 进行升级，到时候会再记录一下，以上。

TroubleShooting:

升级完成以后其中有一台机器的 jn 不知道为什么忽然信息被清空了。

/dfs/jn/nameservice1/current 下面变成了空白一片，cm 也愉快的报警了这个问题。

重启 jn 查看日志发现相关问题

 

2019-07-29 19:00:20,308 INFO org.apache.hadoop.ipc.Server: IPC Server handler 0 on 8485, call Call#16800 Retry#0 org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocol.heartbeat from 10.222.95.179:34624
java.io.FileNotFoundException: /dfs/jn/nameservice1/current/last-promised-epoch.tmp (No such file or directory)
        at java.io.FileOutputStream.open0(Native Method)
        at java.io.FileOutputStream.open(FileOutputStream.java:270)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
        at org.apache.hadoop.hdfs.util.AtomicFileOutputStream.<init>(AtomicFileOutputStream.java:58)
        at org.apache.hadoop.hdfs.util.PersistentLongFile.writeFile(PersistentLongFile.java:78)
        at org.apache.hadoop.hdfs.util.PersistentLongFile.set(PersistentLongFile.java:64)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.updateLastPromisedEpoch(Journal.java:347)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.checkRequest(Journal.java:462)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.heartbeat(Journal.java:445)
        at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.heartbeat(JournalNodeRpcServer.java:167)
        at org.apache.hadoop.hdfs.qjournal.protocolPB.QJournalProtocolServerSideTranslatorPB.heartbeat(QJournalProtocolServerSideTranslatorPB.java:176)
        at org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocolProtos$QJournalProtocolService$2.callBlockingMethod(QJournalProtocolProtos.java:27403)
        at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:523)
        at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:991)
        at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:869)
        at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:815)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1726)
        at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2675)
2019-07-29 19:00:21,231 ERROR org.apache.hadoop.hdfs.qjournal.server.JournalNode: RECEIVED SIGNAL 15: SIGTERM
2019-07-29 19:00:21,233 INFO org.apache.hadoop.hdfs.qjournal.server.JournalNode: SHUTDOWN_MSG

 

被清空以后没法找到相关文件报出了错误，我 google 了一下相关资料而且发现 namenode 往下下发频率不高

1. action 关闭有问题的 jn 节点。

2. 拷贝正常节点上的日志到该 jn 上。

3. 重启该 jn 让 jn 跟上其余机器。

解决这个问题，可是感受时有 3台 jn 的时候 挂一台不会对 namenode 产生影响，可是挂两台就会，不知道直接移除该 jn 而后再将其加回来是否能不用经过拷贝的相似命令解决该问题。

 

 

Reference:

https://www.cloudera.com/documentation/enterprise/upgrade/topics/ug_cm_upgrade_before.html#cm_upgrade_before

https://www.cloudera.com/documentation/enterprise/upgrade/topics/ug_cdh_upgrade.html

https://cloud.tencent.com/developer/article/1077573  如何升级Cloudera Manager和CDH