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