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