CDH6官方文档中文系列(8)----Cloudera升级指南

Cloudera升级指南

最近在学习cdh6的官方文档，网上也比较难找到中文的文档。
其实官方英文文档的阅读难度其实并不是很高，所以在这里在学习官方文档的过程中，把它翻译成中文，在翻译的过程中加深学习了解，并分享出来和大家一起学习。
中文内容是本人的渣渣英文水平结合有道词典，谷歌翻译的结果，文中部分词语可能翻译的并不准确，希望大家多多提出意见，共同进步。
cdh6的官方中文文档系列长期更新，最后目标整理成gitbook，同大家交流学习。
最后，如果你觉得本文对你有用，希望点个赞给作者一点鼓励哈。

与其感慨路难行不如马上上路，诸位道友，共同学习，加油！-------天南第一剑修

官方文档

以下主题来自Cloudera企业升级指南，提供了使用Cloudera Manager升级Cloudera Manager和CDH的概述和完整流程:

• Overview
• Upgrading Cloudera Manager
• Upgrading CDH
• Upgrading the JDK
• Upgrading the Host Operating System
• Upgrading Cloudera Navigator Data Encryption

概览

将Cloudera企业CDH升级为更高版本的CDH和CDP数据中心。

在开始升级之前，请查看支持升级路径列表，以确保您计划的升级得到支持。在所有版本的Cloudera管理器、CDH或运行时之间不支持升级。请参阅支持的升级路径。

升级包括两个主要步骤:升级Cloudera Manager和升级集群。您不需要同时升级Cloudera管理器和集群，但是Cloudera管理器和集群的版本必须兼容。Cloudera管理器的主+次级版本必须等于或高于CDH或Cloudera运行时的主+次级版本。

关于在线升级指南

这个在线版本的Cloudera升级指南允许您创建一个定制版本的指南，其中只包含升级所需的步骤。使用本指南页面顶部的表格选择用于升级的Cloudera管理器、CDH或Cloudera运行时版本，以及操作系统版本、数据库类型和其他有关升级的信息。做出这些选择之后，指南中的页面将只包括升级所需的步骤。您输入的信息将保留在指南的每一页上

升级到CDP数据中心

从Cloudera Manager和CDH升级到CDP数据中心包括以下高级步骤:

1. 查看关于支持升级路径的升级指南主题。
2. 收集有关部署的信息。
3. 计划如何以及何时开始升级。
4. 将Cloudera Manager升级到7.1.1或更高版本。升级到Cloudera Manager 7.1.1或更高版本后，Cloudera Manager将管理您的集群升级到更高版本。
5. 为集群中部署的组件执行任何必要的迁移前步骤。
6. 使用Cloudera Manager将CDH升级到Cloudera运行时7，或者从Cloudera运行时升级到更高版本的Cloudera运行时。
7. 为集群中部署的组件执行迁移后所需的步骤。

从Cloudera Manager和CDH 5或6升级到更高版本的Cloudera Manager

支持的升级

• 任何CDH 5或6集群到更高版本的CDH
• Cloudera Manager5或6到更高的版本。

从Cloudera Manager和CDH 5或6升级到更高版本的Cloudera Manager包括以下高级步骤:

1. 查看有关受支持升级路径的升级指南主题。
2. 收集有关部署的信息。
3. 计划如何以及何时开始升级。
4. 升级Cloudera Manager。升级Cloudera Manager后，Cloudera Manager将管理您的集群升级到更高版本。
5. 为集群中部署的组件执行任何必要的迁移前步骤。
6. 使用Cloudera管理器升级CDH。
7. 为集群中部署的组件执行迁移后所需的步骤。

请参阅本指南中的主题来计划和执行升级。

评估升级的影响

计划一个足够的维护窗口来执行升级。根据要升级的组件、集群中的主机数量和硬件类型，可能需要一整天的时间来升级集群。在开始升级之前，需要收集一些信息;这些步骤在Cloudera管理器和CDH升级过程中也有详细说明。

在升级之前，请参考Cloudera Manager和CDH的发布说明，了解API的变化、废弃特性、新特性和不兼容的变化。

参见：

• ​ CDP数据中心
  • Cloudera Manager 7.1.1发布说明
  • Cloudera Runtime7.1.1发布说明
• ​ Cloudera企业版
  • Cloudera Enterprise 6发布指南
  • Cloudera企业5.x版本说明

也检查以下页面，以确保您正在使用一个支持的操作系统，JDK，数据库，和其他组件:

• CDP数据中心7.1要求和支持版本
• Cloudera Enterprise 6需求和支持的版本
• cdh5和Cloudera Manager 5需求和支持的版本

重要通知：

Cloudera建议在升级生产集群之前先在非生产集群上测试升级。

有三种类型的升级:major, minor, and maintenance

大版本升级

大版本升级包括以下内容:

• 从Cloudera Manager5.x和cdh5.x升级到Cloudera Manaher6.x和CDH 6.x
• 从Cloudera Manager5.x和cdh5.x升级到Cloudera Manager和Cloudera Runtime 7.1.1或更高
• 从Cloudera Manager和Cloudera Runtime 7.0.3到Cloudera Manager和Cloudera Runtime 7.1.1 (CDP数据中心)
• 来自Cloudera Manager 6.x到Cloudera Manager 7.1.1

大版本的升级通常具有以下特征:

• 对Hadoop的功能进行了重大更改，并将其更新为最新版本
• 数据格式的不兼容更改
• Cloudera Manager对用户界面的重大改变和增加
• 升级过程会自动处理Cloudera Manager的数据库模式更改
• 升级集群需要大量的停机时间。
• 重新部署客户端配置。

小版本的升级

小版本升级将您的软件升级到主版本的高级次要版本(例如从版本6.0.0升级到版本6.1.0)，通常包括以下内容:

• 新功能
• 错误修复
• 自动处理的Cloudera Manager的潜在数据库模式更改
• 重新部署客户端配置。

在小版本升级中通常不会引入不兼容的更改或对数据格式的更改。

维护升级

维护升级修复关键错误或解决安全问题。没有引入新的功能或不兼容的更改。例如，当从版本6.0.0升级到6.0.1时，维护版本的版本号仅在第三位数字上有所不同。

要升级到维护版本，您只需要执行次要版本升级步骤的一个子集。遵循与小版本升级相同的步骤，但跳过标记如下的步骤:

升级Cloudera Manager

最小所需角色:集群管理员(也由完整管理员提供)当使用Cloudera Manager管理数据Hub集群时，该特性不可用。

本主题描述了如何从任意5.x或6.x版本的CM升级到更高版本的Cloudera Manager5.x, 6.x或7.1或更高版本，包括主要、次要和维护版本。升级过程使用操作系统命令行包命令升级Cloudera Manager，然后使用Cloudera Manager完成升级。

升级Cloudera Manager时，使用基于rpm的包命令升级Cloudera Manager服务器主机上的软件，然后Cloudera Manager管理升级剩余托管主机上的Cloudera Manager代理。Cloudera管理器还可以在托管主机上自动安装所需JDK的某些版本。对于CDH集群，当您升级Cloudera管理器时，也会升级Cloudera Manager。

在所有版本的CM、CDH或Cloudera Runtime之间不支持所有的升级。请参阅支持的升级路径

当你升级CM5.x或6.x时，Navigator 也会升级。在Cloudera Runtime7.0.3时，ClouderaNavigator 已经被Apache Atlas取代。如果您使用Cloudera Manager 7.0.3或更高版本来管理CDH集群，这些集群可以继续使用Cloudera Navigator 。

Cloudera Manager升级过程如下:

• 升级数据库模式以反映当前版本。
• 升级Cloudera管理服务器和所有支持服务。
• 升级所有主机上的Cloudera Manager代理。
• 重新部署客户端配置，以确保客户端服务具有最新的配置。
• 升级Cloudera导航器(要升级到Cloudera Manager 7.1，您可以将Cloudera导航器迁移到Apache Atlas)。

要升级Cloudera Manager，您需要执行以下任务:

1. 备份Cloudera Manager服务器数据库、工作目录和其他几个实体。如果在升级过程中出现问题，可以使用这些备份来恢复您的Cloudera Manager部署。
2. 使用命令行中的包命令(例如，RHEL系统上的yum)升级Cloudera Manager服务器软件。Cloudera Manager可以自动完成大部分这个过程，推荐您使用CM升级和管理CDH集群。
3. 升级所有集群主机上的Cloudera Manager代理软件。Cloudera Manager升级向导可以升级代理软件(也可以选择升级JDK)，或者手动安装代理和JDK软件。在此过程中没有升级CDH软件。

如果你从Cloudera Manager 5.x升级到更高版本的Cloudera Manager 5.x。你也可以使用tarballs来升级Cloudera Manager。有关升级到最新版本的Cloudera Manager 5.x的过程，请参阅使用tar包升级Cloudera Manager 5.x。(单击其他版本以找到早期版本的文档。)

升级Cloudera管理器不会升级CDH/Cloudera Runtime集群。有关升级过程，请参阅升级集群。

• Getting Started Upgrading Cloudera Manager
• Backing Up Cloudera Manager
• Upgrading the Cloudera Manager Server
• Upgrading the Cloudera Manager Agents
• After You Upgrade Cloudera Manager
• Troubleshooting a Cloudera Manager Upgrade
• Reverting a Failed Cloudera Manager Upgrade

升级Cloudera导航器组件概述

当您升级Cloudera Manager时，会自动升级Cloudera导航器元数据和审计服务器。您还可以选择升级其他Cloudera导航器组件，如Cloudera导航器密钥托管服务器、Cloudera导航器密钥HSM和Cloudera导航器加密。您不需要将这些组件与Cloudera Manager或CDH升级一起升级。有关兼容性信息，参见:Cloudera Navigator加密的产品兼容性矩阵(Cloudera Manager 6.x)或Cloudera Navigator加密的产品兼容性矩阵(Cloudera Manager 5.x)。

参见升级Cloudera Navigator数据加密。

开始升级Cloudera Manager

在升级Cloudera Manager之前，您需要收集一些信息，并查看其限制和发布说明。填写下面的My Environment表格来定制您的Cloudera管理器升级过程。在查找所需信息方面，请参阅下面的收集信息部分。

选择的环境：

https://docs.cloudera.com/cdp/latest/upgrade-cdh/topics/ug_cm_upgrade_before.html?cdoc-os=redhat%207&cdoc-db=mysql&cdoc-product=none&cdoc-cm-from=6.2.0&cdoc-cm-dest=6.2.1

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XEM2IaBl-1592977491367)(C:\Users\liucz\Desktop!文档\2Linux环境\CDH官方文档\cdh_pic\upgrade_version.jpg)]

要与他人共享此环境，请单击我的环境旁边的图标，将特定于此环境的链接复制到剪贴板。

收集信息

• 登录到Cloudera Manager服务器主机

• 收集以下关于您的环境的信息，并填写上面的表格。您的浏览器将在本升级指南的所有页面上记住这些信息。

  ​ a. 操作系统的当前版本

  lsb_release -a
  

  Database 参数:

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

  ...
  com.cloudera.cmf.db.type=mysql
  com.cloudera.cmf.db.host=database_hostname:database_port
  com.cloudera.cmf.db.name=scm
  com.cloudera.cmf.db.user=scm
  com.cloudera.cmf.db.password=SOME_PASSWORD
  

  ​ b. 登录到Cloudera Manager管理控制台并找到以下内容

  • 集群中使用的CM 版本。去支持>关于。

  • 部署在集群中的JDK版本。去支持>关于。

准备升级Cloudera Manager

• 您必须使用SSH访问Cloudera Manager服务器主机，并能够使用根帐户或对所有主机具有无密码sudo权限的帐户登录。

• 升级到Cloudera Manager 6.x时查看以下内容:

  • ​ Cloudera Enterprise 6 Requirements and Supported Versions
  • ​ Supported Upgrade Paths

• 在升级Cloudera管理器之前，您应该已经升级到支持的操作系统。参见升级操作系统。

• 在所有主机上安装Java Development Kit (JDK)的支持版本。如果你升级到Cloudera Manager和CDH版本6.1或更高，你可以选择安装OpenJDK 1.8而不是Oracle JDK。

  JDK安装有两种选择:

  • 在所有主机上手动安装Oracle JDK或OpenJDK。
  • 在Cloudera Manager主机上手动安装Oracle JDK 1.8，然后在运行Cloudera Manager升级向导的提示时选择install Oracle Java SE Development Kit复选框。

  参见

• 查看发布说明

  • Cloudera Enterprise
    • Cloudera Enterprise 6 Release Guide
    • Cloudera Enterprise 5.x Release Notes
  • Hortonworks Data Platform
    • HDP 2.6.5 Release Notes

• 检查一下Cloudera的安全公告。

• 使用tarball升级Cloudera Manager只支持升级到5.x，现在已被弃用。

备份Cloudera Manager

本主题包含备份Cloudera Manager的过程。Cloudera建议您在升级之前执行这些备份步骤。备份将允许您在需要时回滚您的Cloudera管理器升级。

选择的环境：

CM 6.2.0-6.2.1

第1步 为备份Cloudera管理器收集信息

1. 登录到Cloudera Manager服务器主机

2. 通过运行以下命令收集数据库信息

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

举例

...
com.cloudera.cmf.db.type=...
com.cloudera.cmf.db.host=database_hostname:database_port
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=SOME_PASSWORD

3. 收集以下数据库的信息(主机名、端口号、数据库名、用户名和密码)。

   • Reports Manager
   • Navigator Audit Server
   • Navigator Metadata Server
   • Activity Monitor

   您可以使用Cloudera Manager管理控制台找到数据库信息。转到集群> Cloudera管理服务>配置，并选择数据库类别。您可能需要联系数据库管理员以获得密码。

4. 查找运行服务监视器、主机监视器和事件服务器角色的主机。转到集群> Cloudera Manager管理服务>实例，注意哪些主机正在运行这些角色。

第2步 备份Cloudera Manager Agent

请注意

下面提供了用于备份Cloudera Manager代理使用的各种文件和目录的命令。如果您已经为其中任何一个配置了自定义路径，请在命令中替换这些路径。这些命令还提供了存储备份的目标路径，该路径由环境变量CM_BACKUP_DIR定义，所有备份命令都使用该环境变量。您可以根据部署需要在命令中更改这些目标路径。

下面步骤中的tar命令可能返回以下消息。忽略这个信息是安全的:

tar: Removing leading `/' from member names

在所有主机上备份以下Cloudera Manager代理文件:

• 创建一个顶级备份目录

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

• 备份代理目录和运行时状态。

  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
  

第3步：备份Cloudera Management Service

注意

下面提供了用于备份Cloudera Manager代理使用的各种文件和目录的命令。如果您已经为其中任何一个配置了自定义路径，请在命令中替换这些路径。命令还提供了存储备份的目标路径。您可以根据部署需要在命令中更改这些目标路径。

1. 在配置运行服务监视器角色的主机上，备份以下目录

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

2. 在配置运行主机监视器角色的主机上，备份以下目录

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

3. 在配置运行事件服务器角色的主机上，备份以下目录

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

第4步：停止Cloudera Manager Server & Cloudera Management Service

1. 停止Cloudera Management Service
2. 登入Cloudera Manager Server的主机
3. 停止Cloudera Manager Server

sudo systemctl stop cloudera-scm-server

第5步：备份Cloudera Manager server database

1. 备份Cloudera Manager server database——运行以下命令。(下面显示的命令取决于您在此页顶部的表单中选择的数据库。用数据库返回的实际值替换占位符。属性文件):

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

请注意

如果db。属性文件不包含端口号，请忽略上面命令中的端口号参数。

有关备份数据库的详细信息，请参见备份数据库。

2. 备份所有其他Cloudera Manager数据库——使用在上一步中收集的数据库信息。您可能需要联系数据库管理员以获得密码。

   这些数据库可包括下列资料:

   • Cloudera Manager服务器——包含您配置的服务的所有信息，以及它们的角色分配、所有配置历史、命令、用户和正在运行的进程。这个相对较小的数据库(< 100 MB)是最需要备份的。

   • Oozie服务器——包含Oozie工作流、协调器和捆绑数据。可以增长到很大。(仅在安装cdh5或cdh6集群时可用。)

   • Sqoop服务器——包含连接器、驱动程序、链接和作业等实体。相对较小。(仅在安装cdh5或cdh6集群时可用。)

   • 报告管理器-随时间跟踪磁盘利用率和处理活动。中型。

   • Hive元数据服务器-包含Hive元数据。相对较小。

   • Hue服务器-包含用户帐户信息，工作提交，和Hive查询。相对较小。

   • Sentry 服务器-包含授权元数据。相对较小。

   • Cloudera Navigator审计服务器-包含审计信息。在大型集群中，这个数据库可以增长到很大。(仅在安装cdh5或cdh6集群时可用。)

   • Cloudera Navigator元数据服务器——包含授权、策略和审计报告元数据。相对较小。(仅在安装cdh5或cdh6集群时可用。)

     重要的

     当您重新启动进程时，每个服务的配置将使用保存在Cloudera Manager数据库中的信息重新部署。如果此信息不可用，则集群无法正确启动或运行。您必须计划和维护对Cloudera Manager数据库的定期备份，以便在数据库丢失时恢复集群。

     运行以下命令备份数据库。(下面显示的命令取决于您在此页顶部的表单中选择的数据库。用实际值替换占位符。)

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

第6步：备份Cloudera Manager Server

请注意

下面提供了用于备份Cloudera Manager代理使用的各种文件和目录的命令。如果您已经为其中任何一个配置了自定义路径，请在命令中替换这些路径。这些命令还提供了存储备份的目标路径，该路径由环境变量CM_BACKUP_DIR定义，所有备份命令都使用该环境变量。您可以根据部署需要在命令中更改这些目标路径。

下面步骤中的tar命令可能返回以下消息。忽略这个信息是安全的:

tar: Removing leading `/' from member names

1. 登录到Cloudera Manager服务器主机。

2. 创建一个顶级备份目录。

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

3. 备份Cloudera Manager Server目录:

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

4. 备份现有的存储库目录

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

第7步：(可选)启动Cloudera Manager Server & Cloudera Management Service

启动Cloudera Manager Server & Cloudera Management Service

如果您将立即升级Cloudera Manager，请跳过这一步，继续升级Cloudera Manager Server。

1. 登录到Cloudera Manager服务器主机。

2. 启动Cloudera Manager Server。

   sudo systemctl start cloudera-scm-server
   

如果Cloudera管理器服务器在没有错误的情况下启动，则不会显示响应。

3. 启动Cloudera Management Service。告诉我如何

备份数据库

Cloudera建议您定期备份Cloudera Manager用于存储配置、监控和报告数据的数据库，以及需要数据库的托管服务:

备份PostgreSQL数据库

要备份PostgreSQL数据库，无论数据库是内嵌还是外嵌，都要使用相同的过程:

1. 登录安装Cloudera Manager服务器的主机。

2. 从/etc/ cloudera -scm-server/db.properties获取Cloudera管理器数据库的名称、用户和密码属性:

   com.cloudera.cmf.db.name=scm
   com.cloudera.cmf.db.user=scm
   com.cloudera.cmf.db.password=NnYfWIjlbk
   

3. 使用来自前一步的参数以root身份运行以下命令:

   # pg_dump -h hostname -p 7432 -U scm > /tmp/scm_server_db_backup.$(date +%Y%m%d)
   

4. 从步骤2中的com.cloudera.cmf.db.password属性输入密码。。

5. 备份为本地主机上的角色作为roleuser用户创建的数据库

   # pg_dump -h hostname -p 7432 -U roleuser > /tmp/roledb
   

备份MariaDB数据库

要备份MariaDB数据库，在MariaDB主机上运行mysqldump命令，如下所示:

mysqldump -hhostname -uusername -ppassword database > /tmp/database-backup.sql

例如，备份为Cloudera软件创建数据库时创建的活动监控数据库amon，在本地主机上作为根用户，密码为amon_password:

mysqldump -pamon_password amon > /tmp/amon-backup.sql

为了备份远程主机myhost.example.com上的示例活动监视器数据库amon作为root用户，密码为amon_password:

mysqldump -hmyhost.example.com -uroot -pamon_password amon > /tmp/amon-backup.sql

备份MySQL数据库

为了备份MySQL数据库，在MySQL主机上运行mysqldump命令，如下所示:

mysqldump -hhostname -uusername -ppassword database > /tmp/database-backup.sql

例如，备份为Cloudera软件创建数据库时创建的活动监控数据库amon，在本地主机上作为根用户，密码为amon_password:

mysqldump -pamon_password amon > /tmp/amon-backup.sql

为了备份远程主机myhost.example.com上的示例活动监视器数据库amon作为根用户，密码为amon_password:

mysqldump -hmyhost.example.com -uroot -pamon_password amon > /tmp/amon-backup.sql

您可以备份所有数据库使用以下命令:

mysqldump --all-databases -ppassword > /tmp/all1/all.sql

备份Oracle数据库

对于Oracle，与数据库管理员一起确保数据库得到了正确的备份。

数据库供应商资源

使用以下链接访问厂商关于备份和恢复数据库的文档。

• MariaDB 5.5: http://mariadb.com/kb/en/mariadb/backup-and-restore-overview/
• MySQL 5.5: http://dev.mysql.com/doc/refman/5.5/en/backup-and-recovery.html
• MySQL 5.6: http://dev.mysql.com/doc/refman/5.6/en/backup-and-recovery.html
• PostgreSQL 8.4: https://www.postgresql.org/docs/8.4/static/backup.html
• PostgreSQL 9.2: https://www.postgresql.org/docs/9.2/static/backup.html
• PostgreSQL 9.3: https://www.postgresql.org/docs/9.3/static/backup.html
• Oracle 11gR2: http://docs.oracle.com/cd/E11882_01/backup.112/e10642/toc.htm

升级Cloudera Manager Server

本主题提供了备份Cloudera Manager服务器的过程。

**最小所需角色:集群管理员(也由完整管理员提供)**在使用Cloudera管理器管理数据中心集群时，他的特性是不可用的。

RedHat/CentOS7

MySQL

6.2.0-6.2.1

重要的
Cloudera Manager或CDH 6.3.3或更高版本的升级和安装过程已经改变。请注意以下内容:

• 下载和安装该软件需要一个有效的Cloudera企业许可证文件以及用户名和密码。您可以从Cloudera CDH下载页面获得用户名和密码。查看您的许可证文件必须是当前上传到Cloudera管理器。
• 上传许可证:
  • 下载许可文件并将其保存在本地。
  • 在Cloudera管理器中，进入主页。
  • 选择Administration > License。
  • 点击上传许可证。
  • 浏览到下载的许可文件。
  • 点击上传。
• 你目前使用的是Cloudera试用许可证，你不能升级到Cloudera Manager或CDH 6.3.3或更高版本。
• 如果您正在使用Cloudera Express，您不能升级Cloudera Manager或CDH。
• 过程中的几个步骤已经更改，现在需要输入用户名和密码。
• 下载url已经改变。

重要提示

如果遇到问题，请参阅以下内容:

• 解决Cloudera管理器升级问题
• 恢复失败的Cloudera管理器升级

第1步：建立对软件的访问

Cloudera管理器需要访问包含更新的软件包的软件包存储库。你可以选择直接访问Cloudera公共存储库，也可以下载这些存储库，然后在本地设置一个存储库，以便在网络中访问。如果集群主机没有Internet连接，则必须设置本地存储库。

1. 登录到Cloudera Manager服务器主机。

2. 登录到Cloudera Manager服务器主机。

sudo rm /etc/yum.repos.d/clouderamanager.repo
```

3. 把这张表格填在这页的顶部。

4. 创建一个存储库文件，以便包管理器能够定位和下载二进制文件。根据您是否使用本地包存储库，执行以下操作之一:

   • 使用本地包存储库。(当集群主机不能访问internet时需要。)
     • 配置网络上托管的本地包存储库。
     • 在包存储库URL中，将整个URL替换为本地包存储库的URL。
     • 点应用
   • 使用Cloudera公共存储库
     • 点应用

   提示

   如果您使用的是混合操作系统环境，请针对每个操作系统调整页面顶部的操作系统过滤器。指南将在这里为您自动生成回购文件。

5. 创建一个名为/etc/ cloud -manager.repo的文件。repo内容如下:

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

6. 升级Cloudera管理器会引入新的包依赖关系。您的组织可能对新软件包的安装有限制，或者需要事先获得批准。您可以确定哪些包可以安装或升级:

   yum deplist cloudera-manager-agent
   

第2步：安装Java (JDK)

所有由Cloudera Manager 6.0.0或更高版本管理的集群主机都需要使用Oracle JDK 1.8。如果你的Cloudera管理器版本支持它，你还可以安装OpenJDK 1.8或OpenJDK 11。请参阅手动安装OpenJDK。如果您的主机上已经安装了JDK 1.8，则跳过本节中的步骤。

如果您升级到Cloudera Manager 6.0.0或更高版本，您可以在Cloudera Manager服务器主机上手动安装JDK 8，然后，作为Cloudera Manager升级过程的一部分，您可以指定Cloudera Manager在其余主机上升级JDK。

1. 登录到Cloudera Manager服务器主机。

2. Stop the Cloudera Manager Server

   sudo systemctl stop cloudera-scm-server
   

3. 移除JDK:

   • 在Cloudera管理器管理的所有主机上执行以下步骤

     • 运行以下命令删除JDK，使用步骤1中的包名:(如果不删除这些文件，Cloudera Manager和其他组件可能继续使用旧版本的JDK)。

       yum remove <JDK package name>
       

     • 确认包裹已被移除:

4. 安装OpenJDK

   OpenJDK 8

   sudo yum install java-1.8.0-openjdk-devel
   

5. Start the Cloudera Manager Server

   sudo systemctl start cloudera-scm-server
   

   如果Cloudera管理器服务器在没有错误的情况下启动，则不会显示响应。

第3步：更新Cloudera Manager Server

1. 登录到Cloudera Manager管理控制台。

2. 停止Cloudera Cloudera Management Service。

   重要提示

   此时不停止Cloudera管理服务可能会导致管理角色崩溃，或者Cloudera管理器服务器可能无法重启。

3. 确保您已经禁用了任何计划的复制或快照作业，并等待来自Cloudera Manager管理控制台的所有运行命令完成后再继续升级。

   重要提示

   如果在停止Cloudera Manager服务器时有复制作业、快照作业或其他命令在运行，那么在升级后Cloudera Manager服务器可能无法启动。

4. 如果您有任何复制到云目的地的Hive复制计划，请在继续升级之前删除这些复制集群。您可以在完成Cloudera Manager升级之后重新创建这些复制计划。

5. 登录到Cloudera Manager服务器主机。

6. Stop the Cloudera Manager Server

   sudo systemctl stop cloudera-scm-server
   

7. Stop the Cloudera Manager Agent

   sudo systemctl stop cloudera-scm-agent
   

8. 升级包

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

   您可能会被提示您的配置文件版本:

   Configuration file '/etc/cloudera-scm-agent/config.ini'
   ==> Modified (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
   Y or I : install the package maintainer's version
   N or O : keep your currently-installed version
   D : show the differences between the versions
   Z : start a shell to examine the situation
   The default action is to keep your current version.
   

   您可能会收到/etc/cloudera-scm-server/db.properties的类似提示。对两个提示都回答N。

   系统可能会提示您接受GPG密钥。回答y。

   Retrieving key from https://archive.cloudera.com/.../cm/RPM-GPG-KEY-cloudera
   Importing GPG key ...
    Userid     : "Yum Maintainer "
    Fingerprint: ...
    From       : https://archive.cloudera.com/.../RPM-GPG-KEY-cloudera
   

   请注意

   如果你在运行这些命令时收到以下错误信息:[Errno 14] HTTP error 404 - Not Found，确保URL在cloudera-manager中。repo文件是正确的，可以从Cloudera Manager服务器主机访问。

9. 如果定制了/etc/cloudera-scm-agent/config.ini文件，那么定制的文件将被重命名为扩展名为.rpmsave或.dpkg-old。将所有定制合并到包管理器安装的/etc/cloudera-scm-agent/config.ini文件中。

10. 验证是否安装了正确的包。

    rpm -qa 'cloudera-manager-*'
    

    cloudera-manager-server-6.2.1-..cm...
    cloudera-manager-agent-6.2.1-..cm...
    cloudera-manager-daemons-6.2.1-..cm...
    

11. Start the Cloudera Manager Agent.

    sudo systemctl start cloudera-scm-agent
    

    如果代理启动时没有错误，则不会显示响应。

12. Start the Cloudera Manager Server.

    sudo systemctl start cloudera-scm-server
    

13. 使用网络浏览器打开Cloudera管理控制台使用以下URL:

    http://cloudera_Manager_server_hostname:7180/cmf/upgrade
    

    Cloudera Manager服务器启动可能需要几分钟时间，并且在服务器启动完成并显示升级Cloudera Manager页面之前，Cloudera Manager管理控制台不可用。在下一页继续执行升级Cloudera Manager代理的步骤。

    注意；

    如果您在启动服务器或代理时遇到问题，例如数据库权限问题，您可以使用日志文件来排除问题:

    服务器日志:

    Server log:

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

    Agent log:

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

    or

    tail -f /var/log/messages
    

要完成Cloudera Manager升级，请继续升级Cloudera Manager代理。

升级Cloudera Manager代理

**最小所需角色:集群管理员(也由完整管理员提供)**当使用Cloudera Manager管理数据Hub集群时，该特性不可用。

升级Cloudera Manager代理(Cloudera Manager 6及以下)

您可以使用下面两种选项中的一种来升级代理。

方法一：使用Cloudera管理器升级代理(推荐)

请注意

如果Cloudera管理器在此过程中显示类似如下的错误信息，你可能有一个旧版本的JDK，这是在干扰升级:

ls: cannot access '/etc/zypp/repos.d/cloudera-manager.repo.*': No such file or directory 
repository file /etc/zypp/repos.d/cloudera-manager.repo removed

升级前删除旧JDK将允许Cloudera管理器完成升级。

如果您在Cloudera Manager服务器主机上升级软件包后，升级Cloudera Manager页面没有显示，请在您的web浏览器中打开以下URL:

https://my_cloudera_manager_server_host:port/cmf/upgrade

代理升级的状态显示在一个或多个组中。因为您可能只升级了Cloudera Manager服务器主机上的Cloudera Manager代理，所以第一组显示该主机有一个升级的代理。如果由Cloudera Manager管理的主机具有不同的操作系统，则每个操作系统的组显示这些主机的代理升级状态。

按照升级页面上的说明升级所有代理。

1. 启动Cloudera Manager管理服务。

2. 如果有不止一组主机需要代理升级，请从标签为Upgrade Cloudera Manager代理包运行在:上的下拉列表中选择该组。如果只有一个组需要升级，则不会出现此下拉列表。

   在Cloudera Manager 5.15或更高版本中，即使代理运行在不同的操作系统或版本上，Cloudera Manager也可以对代理进行升级(每次升级一个操作系统组)。

3. 单击Upgrade Cloudera Manager代理包

   升级Cloudera经理代理包页面显示。

4. 如果您使用的是本地包存储库而不是https://archive.cloudera.com上的公共存储库，请选择定制存储库选项并输入定制存储库URL

5. 单击继续

   将显示接受JDK许可页面。

6. 选择JDK屏幕显示集群中使用的JDK的可用选项。选择以下选项之一安装JDK:

   • 手动管理JDK——如果您已经安装了一个受支持的JDK，请选择此选项。有关安装JDK的信息，请参见升级JDK。
   • 安装一个Cloudera提供的OpenJDK版本——Cloudera管理器在你所有的集群主机上安装OpenJDK 8，除了Cloudera管理器服务器主机。
   • 安装系统提供的OpenJDK版本——Cloudera Manager安装主机操作系统提供的OpenJDK默认版本。

7. 如果您想在所有主机上安装JDK 8，请选择install Oracle Java SE Development Kit。

8. 单击继续。将显示输入登录凭据页面。

9. 指定凭据和初始化代理安装：

   • 为root帐户选择root，或选择另一个用户并为具有无密码sudo权限的帐户输入用户名。
   • 选择一种认证方法:
     • 如果选择“所有主机接受相同密码”选项，请输入并确认密码。
     • 如果选择所有主机接受相同的私钥选项，则提供所需密钥文件的口令和路径。
   • 如果需要，修改默认的SSH端口。
   • 指定同时运行的最大安装数。默认和推荐的值是10。根据您的网络容量调整此参数。

10. 点击继续

    Cloudera管理器代理包和JDK(如果选择的话)将被安装。

11. 安装完成后，单击完成。

    升级Cloudera管理器页面显示升级的状态。

    如果还有其他主机组需要代理升级，请从正在运行的Upgrade Cloudera Manager代理包:下拉列表中选择下一组主机，并重复代理安装步骤。

12. 单击“运行主机检查器”以运行主机检查器。检查输出并纠正任何警告。如果出现问题，您可以进行更改，然后重新运行检查器。

13. 当您对检查结果感到满意时，单击启动Cloudera管理服务。

14. 单击页面底部的链接返回主页。

15. 单击完成。

16. Cloudera Manager主页将打开并显示集群的状态。所有服务显示其当前状态可能需要几分钟时间。您可能需要重新启动一些服务或重新部署陈旧的客户端配置。

方法二：使用命令行升级代理

在Cloudera管理器管理的所有主机上执行以下命令:

(还可以使用csshX、pdsh或pssh等实用工具将同一组命令复用到所有主机。)

1. 使用ssh登录到每个主机。例如:

   ssh host1.example.com
   

2. 删除现有存储库目录中的任何旧文件:

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

3. 创建一个存储库文件，以便包管理器能够定位和下载二进制文件。根据您是否使用本地包存储库，执行以下操作之一:

   • 使用本地包存储库。(当集群主机不能访问internet时需要。)
     • 配置网络上托管的本地包存储库。
     • 在包存储库URL中，将整个URL替换为本地包存储库的URL。
     • 单击Apply。
   • 使用Cloudera公共存储库
     • 点应用

   提示

   如果您使用的是混合操作系统环境，请针对每个操作系统调整页面顶部的操作系统过滤器。指南将在这里为您自动生成repo文件。

4. Stop the Cloudera Manager Agent.

   sudo systemctl stop cloudera-scm-agent
   

5. Oracle JDK 1.8

   sudo yum install oracle-j2sdk1.8.x86_64
   

6. Upgrade the agent packages.

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

   您可能会被提示您的配置文件版本:

   Configuration file '/etc/cloudera-scm-agent/config.ini'
   ==> Modified (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
   Y or I : install the package maintainer's version
   N or O : keep your currently-installed version
   D : show the differences between the versions
   Z : start a shell to examine the situation
   The default action is to keep your current version.
   

   您可能会收到/etc/cloudera-scm-server/db.properties的类似提示。对两个提示都回答N。

7. 如果定制了/etc/cloudera-scm-agent/config.ini文件，那么定制的文件将被重命名为扩展名为.rpmsave或.dpkg-old。将所有定制合并到包管理器安装的/etc/cloudera-scm-agent/config.ini文件中。

8. 验证是否安装了正确的包。

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

9. Start the Cloudera Manager Agent

   sudo systemctl start cloudera-scm-agent
   

10. 在Cloudera Manager 5.15或更高版本中，您可以通过https://my_cloudera_manager_server_host:port/cmf/upgrade监控进程。

11. 升级所有代理后，运行主机检查器。

12. 主机检查器将运行以检查托管主机的正确版本和配置。如果出现问题，您可以进行更改，然后重新运行检查器。

13. Cloudera Manager主页将打开并显示集群的状态。所有服务显示其当前状态可能需要几分钟时间。您可能需要重新启动一些服务或重新部署陈旧的客户端配置。

14. Restart the Cloudera Manager server

    sudo systemctl restart cloudera-scm-server
    

升级Cloudera Manager完成后

最小所需角色:集群管理员(也由完整管理员提供)在使用Cloudera管理器管理数据中心集群时，他的特性是不可用的。

升级Cloudera Navigator加密组件

升级集群中部署的任何Cloudera Navigator加密组件:

• Cloudera Navigator Key Trustee Server
• Cloudera Navigator Key HSM
• Cloudera Navigator Key Trustee KMS
• Cloudera Navigator Encrypt.

如果您仍在使用密钥托管服务器5.4，并且正在升级到Cloudera Manager 5.10或更高版本，那么您必须将密钥托管服务器升级到更最新的版本。

您可以随时升级其他Cloudera导航器组件。在升级Cloudera Manager或CDH时，您不必执行这些升级。

参见升级Cloudera Navigator数据加密

执行升级后的步骤

1. 启动Cloudera管理服务，并在出现提示时调整任何配置。
2. 如果Cloudera Manager在升级后报告旧配置，您可能需要重新启动集群服务并重新部署客户端配置。如果您也在升级CDH，则不需要此步骤。
3. 在Home > Status选项卡上，单击集群名称的旁边，选择Restart并确认。
4. 在Home > Status选项卡上，单击集群名称的旁边，选择部署客户端配置并确认。
5. CM升级完成。如果CM不能正常工作，或者升级没有完成，请参阅CM升级的故障排除。

解决CM升级问题

升级后，Cloudera管理器服务器无法启动

升级后，Cloudera管理器服务器无法启动。

可能的原因

升级之前，有活动命令在运行。这包括用户可能已经运行的命令，以及Cloudera Manager自动触发的命令，这些命令可以用于响应状态更改，也可以用于配置为按计划运行的任务，如备份和灾难恢复复制或快照作业。

可能的解决方法

• 停止任何从Cloudera Manager管理控制台运行的命令，或者等待它们完成。参见中止挂起的命令。
• 确保在继续升级之前，已经从Cloudera Manager管理控制台禁用了任何计划的复制或快照作业。看HDFS复制。

重新运行Cloudera管理器升级向导

最低要求角色:完全管理员。当使用Cloudera Manager管理数据Hub集群时，该特性不可用。

在升级Cloudera Manager软件后，第一次登录到Cloudera Manager服务器时，会运行升级向导。如果您当时没有完成向导，或者您的主机当时不可用，仍然需要升级，您可以重新运行升级向导:

1. 单机主机选项卡。

2. 单击“重新运行升级向导”或查看升级状态。这将带您回到安装向导，根据需要升级主机上的Cloudera Manager代理。

3. 选择要安装的Cloudera Manager代理的版本。通常，这是这个Cloudera Manager服务器的匹配版本。但是，如果您为Cloudera Manager服务器使用自定义存储库(而不是archive.cloudera.com)，请选择自定义存储库并提供所需的信息。自定义存储库允许使用替代位置，但该位置必须包含匹配的代理版本。

4. 指定凭据和初始化代理安装:

   • 为root帐户选择root，或者选择另一个用户并为具有无密码sudo特权的帐户输入用户名。

   • 选择身份验证方法:

     • 如果选择密码身份验证，请输入并确认密码。

     • 如果选择公钥身份验证，请提供所需密钥文件的口令和路径。

     如果需要，可以修改默认的SSH端口。

   • 指定一次运行的主机安装的最大数量。默认和推荐的值是10。
     您可以根据您的网络容量进行调整。

   • 单击Continue。

当您单击Continue时，Cloudera Manager代理将在所有当前管理的主机上升级。您不能通过此过程搜索新的主机。若要向集群添加主机，请单击“将新主机添加到集群”按钮。

恢复失败的Cloudera管理器升级

最小所需角色:集群管理员(也由完整管理员提供)当使用Cloudera Manager管理数据Hub集群时，该特性不可用。

本主题描述如何重新安装您以前使用的相同版本的Cloudera Manager，以便您的Cloudera Manager代理的版本与服务器匹配。下面的步骤假设Cloudera Manager服务器已经停止(因为它在尝试升级后无法启动)。

重要的

下面的说明假设一次Cloudera Manager升级失败，升级后的服务器从未启动，因此升级过程的其余步骤没有执行。下面的步骤不足以从运行中的Cloudera Manager部署进行恢复。

第1步：确保Cloudera管理器服务器和代理已经停止。

1. 登录到Cloudera Manager服务器主机。

2. 停止Cloudera管理器服务器。

   sudo systemctl stop cloudera-scm-server
   

3. 停止Cloudera经理代理。

   sudo systemctl stop cloudera-scm-agent
   

第2步：恢复Cloudera Manager数据库(如果需要)

如果您的Cloudera Manager升级失败，您需要确定升级过程是否成功完成了对Cloudera Manager数据库模式的更新。如果模式更新已经开始，您必须使用在开始升级之前所做的备份来恢复Cloudera Manager数据库。

1. 要确定模式是否已更新，请检查Cloudera Manager服务器日志，并查找类似于以下消息的消息:将模式版本更新到60000。(版本号可能与您的环境不同。)

   运行以下命令来查找日志条目(如果日志文件在不同的位置，替换正确的路径):

   grep 'Updated Schema Version to ' /var/log/cloudera-scm-server/closhelludera-scm-server.log
   

2. 如果需要，恢复数据库

   恢复数据库的过程取决于Cloudera管理器使用的数据库类型。

第3步：建立对软件的访问

Cloudera管理器需要访问包含更新的软件包的软件包存储库。你可以选择直接访问Cloudera公共存储库，也可以下载这些存储库，然后在本地设置一个存储库，以便在网络中访问。如果集群主机没有Internet连接，则必须设置本地存储库。

1. 登录到Cloudera Manager服务器主机。

2. 删除现有存储库目录中的任何旧文件:

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

3. 请填写这一页顶部的表格。

4. 创建一个存储库文件，以便包管理器能够定位和下载二进制文件。根据是否使用本地包存储库，执行以下操作之一:

   • 使用本地包存储库。 (当集群主机不能访问internet时需要。)
     • 配置网络上托管的本地包存储库。
     • 在包存储库URL中，将整个URL替换为本地包存储库的URL。
     • 单击Apply。
   • 使用Cloudera公共存储库
     • 单击Apply

提示

如果您使用的是混合操作系统环境，请针对每个操作系统调整页面顶部的操作系统过滤器。指南将在这里为您自动生成repo文件。

5. 创建一个名为/etc/yum.repos.d/cloudera-manager.repo的文件。内容如下:

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

6. 升级Cloudera管理器会引入新的包依赖关系。您的组织可能对新软件包的安装有限制，或者需要事先获得批准。您可以确定哪些包可以安装或升级:

   yum deplist cloudera-manager-agent
   

第4步：降级Cloudera管理程序包

请注意

在升级之前，确保上面的存储库文件与特定的维护版本匹配。

1. 降级的包

   sudo yum clean all
   sudo yum repolist
   sudo yum downgrade "cloudera-manager-*"
   

2. 验证是否安装了正确的包。

   rpm -qa 'cloudera-manager-*'
   cloudera-manager-server-6.2.1-..cm...
   cloudera-manager-agent-6.2.1-..cm...
   cloudera-manager-daemons-6.2.1-..cm...
   

第5步：恢复Cloudera管理器目录

1. 运行以下命令提取备份

   cd $CM_BACKUP_DIR
   tar -xf cloudera-scm-agent.tar
   tar -xf cloudera-scm-server.tar
   

2. 从升级过程中的备份中恢复Cloudera Manager服务器目录:

   sudo -E cp -rp $CM_BACKUP_DIR/etc/cloudera-scm-server/* /etc/cloudera-scm-server
   sudo -E cp -rp $CM_BACKUP_DIR/etc/default/cloudera-scm-server /etc/default/cloudera-scm-server
   

3. 如果Cloudera Manager服务器主机安装了代理，则从升级过程中备份的Cloudera Manager代理目录中恢复:

   sudo -E cp -rp $CM_BACKUP_DIR/etc/cloudera-scm-agent/* /etc/cloudera-scm-agent
   sudo -E cp -rp $CM_BACKUP_DIR/etc/default/cloudera-scm-agent /etc/default/cloudera-scm-agent
   sudo -E cp -rp $CM_BACKUP_DIR/var/run/cloudera-scm-agent/* /var/run/cloudera-scm-agent
   sudo -E cp -rp $CM_BACKUP_DIR/var/lib/cloudera-scm-agent/* /var/lib/cloudera-scm-agent
   

第6步：再次启动Cloudera管理器

1. Start the Cloudera Manager Agent.

   sudo systemctl start cloudera-scm-agent
   

   如果代理启动没有错误，则不会显示响应。

2. Start the Cloudera Manager Server

   sudo systemctl start cloudera-scm-server
   

   如果Cloudera管理器服务器启动没有错误，则不会显示响应。

3. Start the Cloudera Management Service

注意：

进行故障排除:如果您启动服务器时遇到问题，比如数据库权限问题，您可以使用服务器的日志来排除问题。

vim /var/log/cloudera-scm-server/cloudera-scm-server.log

升级CDH(集群升级)

最小所需角色:集群管理员(也由完整管理员提供)当使用Cloudera Manager管理数据Hub集群时，该特性不可用。

本主题描述如何在以下情况下升级CDH或Cloudera Runtime 集群:

• From any 5.x version to a higher version of CDH.
• From CDH 5.13 or higher to Cloudera Runtime 7.1 or higher.
• From Cloudera Runtime to a higher version of Cloudera Runtime.
• Upgrade CDH or Cloudera Runtime to maintenance releases.

升级集群时，可以使用Cloudera Manager在整个集群中升级集群软件，可以使用Cloudera包裹，也可以使用基于rpm的包命令。基于包的安装不支持Cloudera Runtime 和CDP数据中心升级。在升级到CDP数据中心之前，必须先迁移CDH集群以使用包裹。

集群升级更新Hadoop软件和其他组件。您可以使用Cloudera Manager升级集群，进行主要、次要和维护升级。过程的不同取决于您使用的Cloudera管理器版本和您升级到的CDH或Cloudera运行时版本。

完成准备步骤后，使用Cloudera Manager升级向导完成升级。如果您使用了包裹(推荐)、启用了HDFS高可用性并拥有Cloudera企业许可证，那么您可以执行滚动升级，在升级期间不需要使集群离线。

请注意

升级到CDP数据中心时不支持滚动升级。

有关集群升级步骤，请参见升级集群。

开始升级集群

在升级集群之前，需要收集信息、检查限制和发布说明，并对集群运行一些检查。请参阅下面的收集信息部分。填写下面的My Environment表单来定制您的CDH升级过程。

CDH或Cloudera Runtime 的版本，可以根据管理集群的Cloudera管理器的版本升级。您可能需要在升级集群之前升级Cloudera Manager当使用Cloudera Manager 7.0.3时，集群不支持升级。

最小所需角色:集群管理员(也由完整管理员提供)当使用Cloudera Manager管理数据Hub集群时，该特性不可用。

警告

CDH 6.2.0中的Kafka基于Apache Kafka 2.1.0，其中包含对用于存储消费者偏移量的内部模式的更改。由于这个变化，一旦卡夫卡已经升级到CDH 6.2.0或更高,无法降级kafka到一个低于CDH 6.2.0的版本。

收集信息

收集以下关于您的环境的信息，并填写上面的表格。您的浏览器将在本升级指南的所有页面上记住这些信息。

1. 登录到Cloudera Manager服务器主机。

2. 运行以下命令查找操作系统的当前版本

   lsb_release -a
   

3. 登录到Cloudera Manager管理控制台并找到以下内容:

   • 集群中使用的Cloudera Manager版本。去支持>关于。
   • 部署在集群中的JDK版本。去支持>关于。
   • HDFS是否启用了高可用性。转到HDFS服务并单击Actions按钮。如果您看到禁用高可用性，则集群启用了高可用性。
   • 安装方法和当前集群版本。集群(CDH)版本号和安装方法显示在Cloudera Manager主页上集群名称右侧。

准备升级集群

1. 您必须使用SSH访问Cloudera Manager服务器主机，并能够使用根帐户或对所有主机具有无密码sudo权限的帐户登录。

2. 检查您要升级到的新版本的需求和支持版本。参见:

   • CDP Data Center 7.1 Requirements and Supported Versions
   • Cloudera Enterprise 6 Requirements and Supported Versions
   • CDH 5 and Cloudera Manager 5 Requirements and Supported Versions

   如果您的主机需要操作系统升级，您必须在升级集群之前执行升级。参见升级操作系统。

3. 确保集群中的所有主机上都安装了受支持的Java版本。参见上面的链接。有关安装说明和建议，请参见升级JDK。

4. 查看以下文档:

   • 升级到Cloudera Manager 6.x时查看以下内容。

     • Cloudera Enterprise 6的需求和支持的版本

     • 支持的升级路径。

   • Cloudera安全公告

5. 检查升级过程并预留一个维护窗口，分配足够的时间来执行所有步骤。对于生产集群，Cloudera建议分配一个全天的维护窗口来执行升级，具体取决于主机数量、您对Hadoop和Linux的经验以及您使用的特定硬件。

6. 如果集群使用Impala，请检查SQL中不兼容更改中列出的最新保留字。如果跨多个版本升级，或者出现任何问题，请检查完整的Impala保留字列表。

7. 运行安全检查器并修复任何报告的错误。

   转到管理>安全>安全检查器

8. 作为hdfs用户登录到任何集群节点，运行以下命令，并纠正任何报告的错误:

   hdfs fsck / -includeSnapshots
   

   请注意

   fsck命令可能需要10分钟或更长时间才能完成，具体取决于集群中的文件数量。

   hdfs dfsadmin -report
   

   请参阅Apache Hadoop文档中的HDFS命令指南。

9. 作为hdfs用户登录到任何DataNode，运行以下命令，并纠正任何报告的错误:

   hbase hbck 
   

10. 如果集群使用Kudu，登录到任何集群主机并作为Kudu用户运行ksck命令(sudo -u Kudu)。如果集群是Kerberized，首先以kudukinit，然后运行命令:

    kudu cluster ksck <master_addresses>
    

    有关此命令的完整语法，请参见使用ksck检查集群运行状况。

11. 如果你升级到CDH 6.0或更高，并且Hue部署在集群中，并且使用PostgreSQL作为它的数据库，你必须手动安装psycopg2。参见安装Hue的依赖项。

12. 如果您的集群使用Sentry和Oracle数据库，并且您正在从CDH 5.13.0或更高版本升级到CDH 5.16.0或更高版本，或者升级到CDH 6.1.0或更高版本，那么您必须手动添加AUTHZ_PATH。AUTHZ_OBJ_ID索引(如果它不存在)。手动添加索引可以减少哨兵获取完整的HDFS同步快照所需的时间。使用以下命令添加索引:

    CREATE INDEX "AUTHZ_PATH_FK_IDX" ON "AUTHZ_PATH" ("AUTHZ_OBJ_ID");
    

13. 从CDH 6.0.0开始，以下服务不再被支持:

• Accumulo
• Sqoop 2
• MapReduce 1
• Spark 1.6
• Record Service

在升级集群之前，必须停止并删除这些服务。

14. 打开Cloudera Manager管理控制台，收集关于您的环境的以下信息:

• Cloudera管理器版本。去支持>关于。
• 部署的JDK版本。去支持>关于。
• CDH的版本以及集群是使用包还是包安装的。它显示在主页上集群名称的旁边。
• 集群中启用的服务。
• 是否启用HDFS高可用性。

15. 开始升级之前备份Cloudera管理器。参见备份CM。

备份集群

本主题描述如何在升级集群之前备份由Cloudera Manager管理的集群。这些过程不备份存储在集群中的数据。Cloudera建议您使用Cloudera管理器的备份和灾难恢复功能定期备份数据。

最低要求角色:完全管理员。当使用Cloudera Manager管理数据Hub集群时，该特性不可用。

在升级之前备份集群允许您在必要时回滚升级。请参阅回滚将cdh5到cdh6的升级。(不支持从cdh5.x升级到cdh5.x的回滚。)

以下CDH组件不需要备份:

• MapReduce
• YARN
• Spark
• Pig
• Impala

在升级集群之前，请完成以下备份步骤:

第一步：备份数据库

警告

备份数据库需要您停止一些服务，这可能使它们在备份期间不可用。

收集以下信息:

• 数据库类型(PostgreSQL、嵌入式PostgreSQL、MySQL、MariaDB或Oracle)
• 数据库的主机名
• 数据库名称
• 数据库使用的端口号
• 数据库凭据

打开Cloudera Manager管理控制台，查找您在集群中部署的以下服务的数据库信息:

• Sqoop、Oozie和Hue——转到集群名称>配置>数据库设置

请注意

Sqoop转移使用一个HyperSQL (HSQLDB)数据库。有关备份过程，请参阅HyperSQL文档。

• Hive 元数据-到hive服务，选择配置，并选择Hive Metastore Database****类别。

备份数据库

对备份的每个数据库执行以下步骤:

1. 如果还没有停止，停止服务。如果Cloudera管理器指出存在依赖服务，也要停止依赖服务。

   • 在Home > Status选项卡上，单击服务名称的右侧并选择停止。

   • 在下一个屏幕中单击停止确认。当您看到完成状态时，表示服务已停止。

2. 备份数据库。替换数据库名、主机名、端口、用户名和备份目录路径，运行以下命令:

   MySQL

   mysqldump --databases
   database_name
   --host=database_hostname
   --port=database_port -u
   database_username -p >
   backup_directory_path/database_name-backup-`date
   +%F`-CDH6.2.0.sql
   

   PostgreSQL/Embedded

   pg_dump -h database_hostname -U database_username -W -p database_port database_name > backup_directory_path/database_name-backup-`date +%F`-CDH6.2.0.sql
   

   Oracle

   与数据库管理员一起确保数据库得到了正确的备份。

   有关备份数据库的其他信息，请参见这些特定于供应商的链接:

   • MariaDB 5.5: http://mariadb.com/kb/en/mariadb/backup-and-restore-overview/
   • MySQL 5.5: http://dev.mysql.com/doc/refman/5.5/en/backup-and-recovery.html
   • MySQL 5.6: http://dev.mysql.com/doc/refman/5.6/en/backup-and-recovery.html
   • PostgreSQL 8.4: https://www.postgresql.org/docs/8.4/static/backup.html
   • PostgreSQL 9.2: https://www.postgresql.org/docs/9.2/static/backup.html
   • PostgreSQL 9.3: https://www.postgresql.org/docs/9.3/static/backup.html
   • Oracle 11gR2: http://docs.oracle.com/cd/E11882_01/backup.112/e10642/toc.htm
   • HyperSQL: http://hsqldb.org/doc/guide/management-chapt.html#mtc_backup

3. 启动服务。

   • 在Home > Status选项卡上，单击服务名称的右侧并选择启动。

   • 在下一个屏幕中单击Start确认。当您看到完成状态时，表示服务已经启动。

第二步：备份ZooKeeper

在所有ZooKeeper主机上，备份ZooKeeper配置中使用dataDir属性指定的ZooKeeper数据目录。默认位置是/var/lib/zookeeper。例如:

cp -rp /var/lib/zookeeper/ /var/lib/zookeeper-backup-`date +%F`CM6.2.0-CDH6.2.0

要识别ZooKeeper主机，打开Cloudera Manager管理控制台，转到ZooKeeper服务并单击实例选项卡。

记录文件和目录的权限;你需要这些来击退ZooKeeper。

第三步：备份Search

使用以下过程备份Solr元数据。如果在升级过程中出现任何问题，此过程允许您回滚到升级前状态。

1. 确保HDFS和ZooKeeper服务正在运行。
2. 停止Solr服务(Solr服务>行动>停止)。如果看到有关停止依赖服务的消息，请先单击关闭并停止依赖服务，然后停止Solr服务。
3. 确保为升级备份目录配置属性指定的目录存在于HDFS中，并且可以由搜索超级用户(默认为solr)写入。
4. 备份Solr配置元数据(Solr service >行动>为升级备份Solr配置元数据)。
5. 启动Solr服务(Solr服务>行动>启动)。
6. 启动已停止的任何依赖服务。

第四步：备份Apache Kudu

在开始升级过程之前，请查看Kudu 1.12的升级说明。

通过运行以下命令，使用Kudu -backup-tools jar将Kudu中的所有数据备份到HDFS或AWS S3中。集群升级后，您可以在新集群上恢复这些数据，并再次开始使用Kudu。

spark-submit --class org.apache.kudu.backup.KuduBackup kudu-backup2_2.11-1.12.0.jar  --kuduMasterAddresses master1-host,master-2-host,master-3-host --rootPath hdfs:///kudu-backups table_name

其中

• hdfs:///kudu-backup是您希望存储备份的路径。
• master1-host,master-2-host,master-3-host是Kudu master的实际主机名。

第五步：备份HDFS

按照以下步骤备份HDFS部署。

请注意

要找到备份HDFS所需的主机名(日志节点、datanode和namenode)，打开Cloudera Manager管理控制台，转到HDFS服务，然后单击实例选项卡。

1. 如果HDFS启用了高可用性，那么在所有运行JournalNode角色的主机上运行以下命令:

   cp -rp /dfs/jn /dfs/jn-CM6.2.0-CDH6.2.0
   

2. 在所有NameNode主机上，备份NameNode运行时目录。运行以下命令:

   mkdir -p /etc/hadoop/conf.rollback.namenode
   
   cd /var/run/cloudera-scm-agent/process/ && cd `ls -t1 | grep -e "-NAMENODE\$" | head -1`
   
   cp -rp * /etc/hadoop/conf.rollback.namenode/
   
   rm -rf /etc/hadoop/conf.rollback.namenode/log4j.properties
   
   cp -rp /etc/hadoop/conf.cloudera.HDFS_service_name/log4j.properties /etc/hadoop/conf.rollback.namenode/
   

   这些命令创建一个临时回滚目录。如果回滚到cdh5.x，后面回滚过程需要您修改此目录中的文件。

3. 备份所有Datanodes的目录。在所有datanode上运行以下命令:

   mkdir -p /etc/hadoop/conf.rollback.datanode/
   
   cd /var/run/cloudera-scm-agent/process/ && cd `ls -t1 | grep -e "-DATANODE\$" | head -1`
   
   cp -rp * /etc/hadoop/conf.rollback.datanode/
   
   rm -rf /etc/hadoop/conf.rollback.datanode/log4j.properties
   
   cp -rp /etc/hadoop/conf.cloudera.HDFS_service_name/log4j.properties /etc/hadoop/conf.rollback.datanode/
   

4. 如果HDFS没有启用高可用性，则备份辅助NameNode的目录时。在所有Secondary NameNode主机上运行以下命令:

   mkdir -p /etc/hadoop/conf.rollback.secondarynamenode/
   
   cd /var/run/cloudera-scm-agent/process/ && cd `ls -t1 | grep -e "-SECONDARYNAMENODE\$" | head -1`
   
   cp -rp * /etc/hadoop/conf.rollback.secondarynamenode/
   
   rm -rf /etc/hadoop/conf.rollback.secondarynamenode/log4j.properties
   
   cp -rp /etc/hadoop/conf.cloudera.HDFS_service_name/log4j.properties /etc/hadoop/conf.rollback.secondarynamenode/
   

第六步：备份密钥托管服务器和客户端

有关详细过程，请参阅备份和恢复密钥受托人服务器和客户机。

第七步：备份HSM KMS

在高可用性模式下运行HSM KMS时，如果两个节点中的任何一个出现故障，则可以将一个角色实例分配给另一个节点，并由剩下的活动节点联合到服务中。换句话说，您可以将作为集群一部分但没有运行HSM KMS角色实例的节点引入到服务中，方法是将其变成一个HSM KMS角色实例(更具体地说，是一个HSM KMS代理角色实例和一个HSM KMS转移角色实例)。因此，每个节点充当另一个节点的在线(“热”备份)备份。在许多情况下，这就足够了。但是，如果需要对从头恢复服务所需的文件进行手动(“冷”备份)备份，您也可以创建该备份。

要创建备份，需要在一个或多个运行HSM KMS角色实例的节点上复制/var/lib/hsmkp和/var/lib/hsmkp-meta目录。

要从备份中恢复:在第一次启动HSM KMS之前，启动一个完全新的HSM KMS服务实例，并将备份中的/var/lib/hsmkp和/var/lib/hsmkp-meta目录复制到恢复的节点的文件系统上。

第八步：备份Navigator Encrypt

建议您在安装后备份Navigator加密配置目录，并在任何配置更新后再次备份。

1. 手动备份导航器加密配置目录(/etc/navencrypt):

   $ zip -r --encrypt nav-encrypt-conf.zip /etc/navencrypt
   

   --encrypt选项提示您创建用于加密zip文件的密码。解密文件也需要此密码。确保您将密码存储在一个安全的位置以保护它。

2. 将备份文件(nav-encrypt-conf.zip)移动到安全位置。

警告

如果无法备份配置目录，则备份的加密数据在数据丢失时将无法恢复。

第九步：备份HBase

因为回滚过程也回滚HDFS，所以HBase中的数据也回滚。此外，存储在ZooKeeper中的HBase元数据将作为ZooKeeper回滚过程的一部分恢复。

如果集群配置为使用HBase复制，Cloudera建议记录所有复制节点。如果需要(例如，因为HBase znode已经被删除)，您可以在不使用ZooKeeper元数据的情况下，作为HDFS回滚的一部分回滚HBase。该元数据可以在新的ZooKeeper安装中重新构建，但复制对等点除外，必须将其添加回来。有关启用HBase复制、列出对等点和添加对等点的信息，请参阅cdh5文档中的HBase复制。

第十步：备份Sqoop 2

请注意

CDH 6.x中不支持Sqoop 2。升级到cdh6。在升级之前，必须删除Sqoop 2服务。在删除Sqoop 2服务之前执行这些步骤。

如果没有为Sqoop 2使用默认的嵌入式Derby数据库，则备份为Sqoop 2配置的数据库。否则，备份Sqoop 2 metastore目录的repository子目录。这个位置是用Sqoop 2服务器转移目录属性指定的。默认位置是:/var/lib/sqoop2对于这个默认位置，Derby数据库文件位于/var/lib/sqoop2/repository中。

第十一步：备份Hue

1. 在所有运行Hue服务器角色的主机上，备份应用注册表文件

mkdir -p /opt/cloudera/parcels_backup
cp -rp /opt/cloudera/parcels/CDH/lib/hue/app.reg /opt/cloudera/parcels_backup/app.reg-CM6.2.0-CDH6.2.0 

升级集群

CDH或Cloudera Runtime的版本，可以根据管理集群的Cloudera管理器的版本升级。当使用Cloudera Manager 7.0.3时，集群不支持升级。

最小所需角色:集群管理员(也由完整管理员提供)当使用Cloudera Manager管理数据Hub集群时，该特性不可用。

注意，如果您正在升级到CDH或Cloudera运行时的维护版本，请跳过标记为[CDH维护版本升级不需要]的任何步骤。

完成CDH升级准备和备份CDH组件的步骤后，继续执行以下升级步骤:

相关信息

在CM升级向导中安装Atlas

使用定制脚本迁移导航器数据

第一步：检查注意事项及警告

在升级集群之前请注意以下事项:

重要提示

• 此过程仅适用于CDH集群。按照此步骤升级密钥托管服务器集群，可以独立执行。
• 如果在集群中使用Solr搜索服务，那么在升级CDH之前和之后都必须执行一些重要的手动步骤。
  在升级到Cloudera运行时之前，请参阅迁移Cloudera Search配置。
• 目前还不支持在CDH 6.0.0集群上运行Apache Accumulo。如果您试图升级到CDH 6.0.0，系统会要求您从集群中删除Accumulo服务。未来的版本将支持在CDH 6之上运行Accumulo。
• 仅支持从CDK 4.1.0升级到Cloudera Runtime 7.1.1或更高版本。如果您运行的是早期版本的CDK，那么在升级到Cloudera Runtime 7.1.1之前，您必须先升级到CDK 4.1.0。

用于执行升级的Cloudera Manager的次级版本必须等于或大于CDH次级版本。要升级Cloudera管理器，请参见升级Cloudera管理器。

• Supported:
  • Cloudera Manager 7.1 and Cloudera Runtime 7.0
  • Cloudera Manager 7.1 and CDH 5.
  • Cloudera Manager 6.0.0 and CDH 5.14.0
  • Cloudera Manager 5.14.0 and CDH 5.13.0
  • Cloudera Manager 5.13.1 and CDH 5.13.3
• Not Supported:
  • Cloudera Manager 5.14.0 and CDH 6.0.0
  • Cloudera Manager 5.12 and CDH 5.13
  • Cloudera Manager 6.0.0 and CDH 5.6

重要提示

Cloudera Manager或CDH 6.3.3或更高版本的升级和安装过程已经改变。请注意以下事项:

• 下载和安装该软件需要一个有效的Cloudera企业许可证文件以及用户名和密码。您可以从Cloudera CDH下载页面获得用户名和密码。查看您的许可证文件必须是当前上传到Cloudera管理器。上传许可证
• 目前使用的是Cloudera试用许可证，你不能升级到Cloudera Manager或CDH 6.3.3或更高版本。
• 如果您正在使用Cloudera Express，您不能升级Cloudera Manager或CDH。
• 过程中的几个步骤已经更改，现在需要输入用户名和密码。
• 下载url已经改变。

警告

CDH 6.2.0中的Kafka基于Apache Kafka 2.1.0，其中包含对用于存储消费者偏移量的内部模式的更改。由于这个变化，kafka已经升级到CDH 6.2.0或更高无法进行降级。

警告

当使用Cloudera Manager备份和灾难恢复(BDR)将集群从Cloudera Manager 5.13或更低的版本备份到CDH 6.0或更高版本时，使用Cloudera Manager备份和灾难恢复(BDR)的数据不起作用。

警告

不支持从CDH 6集群升级到Cloudera Runtime 7。

第二步：备份CM

在升级集群之前，备份Cloudera Manager。即使您只是在升级前备份了Cloudera Manager，您现在也应该备份升级后的Cloudera Manager部署。参见备份CM。

第三步：进入维护模式

为了避免升级过程中出现不必要的警报，在开始升级之前，请在集群上进入维护模式。进入维护模式将停止发送电子邮件警报和SNMP陷阱，但不会停止检查和配置验证。确保在完成升级后退出维护模式，重新启用Cloudera管理器警报。更多的信息。

在Home > Status选项卡上，单击集群名称旁边的actions菜单，并选择进入维护模式。

第四步：运行Hue文档清理

如果您的集群使用Hue，请执行以下步骤(维护版本不需要)。这些步骤清理了Hue使用的数据库表，可以帮助提高升级后的性能。

1. 备份Hue数据库。

2. 连接到Hue数据库。有关连接到色相数据库的信息，请参阅色相组件指南中的色相自定义数据库。

3. 检查desktop_document、desktop_document2、oozie_job、beeswax_session、beeswax_savedquery和beeswax_queryhistory表的大小，以获得参考点。如果其中任何一个有超过100k的行，就运行清理。

   select 'desktop_document' as table_name, count(*) from desktop_document
   union
   select 'desktop_document2' as table_name, count(*) from desktop_document2
   union
   select 'beeswax_session' as table_name, count(*) from beeswax_session
   union
   select 'beeswax_savedquery' as table_name, count(*) from beeswax_savedquery
   union
   select 'beeswax_queryhistory' as table_name, count(*) from beeswax_queryhistory
   union
   select 'oozie_job' as table_name, count(*) from oozie_job
   order by 1;
   

4. 选择一个运行Hue实例的节点，该脚本要求Hue运行并使用Hue的运行配置来运行。通过执行git或wget步骤，将hue_scripts repo下载到任何Hue节点。这些脚本是一组库和命令，需要整个repo。

   wget -qO- -O /tmp/hue_scripts.zip https://github.com/cmconner156/hue_scripts/archive/master.zip && unzip -d /tmp /tmp/hue_scripts.zip
   mv /tmp/hue_scripts-master /opt/cloudera/hue_scripts
   

5. 更改脚本运行器的权限，使其能够运行

   chmod 700 /opt/cloudera/hue_scripts/script_runner
   

6. 在该节点上以root用户的身份运行脚本，命令都是一行，DESKTOP_DEBUG=True是为该命令单独运行的环境设置的，所以你不必跟踪日志:

   DESKTOP_DEBUG=True /opt/cloudera/hue_scripts/script_runner hue_desktop_document_cleanup --keep-days 90
   

7. 如果您包含了上面的DESKTOP_DEBUG，那么日志记录将在控制台中。否则检查/var/log/hue/hue_desktop_document_cleanup.log.

• **注意:**第一次运行通常在每个表中每1000个条目中花费1分钟左右(但根据表的大小，可能花费更长的时间)。

8. 检查desktop_document、desktop_document2、oozie_job、beeswax_session、beeswax_savedquery和beeswax_queryhistory表的大小，并确认它们现在更小了。

   select count(*) from desktop_document;
   select count(*) from desktop_document2;
   select count(*) from beeswax_session;
   select count(*) from beeswax_savedquery;
   select count(*) from beeswax_queryhistory;
   select count(*) from oozie_job;
   

9. 如果任何表的大小仍然大于100k，则再次运行该命令，保留更少的天数

   --keep-days 60 or --keep-days 30
   

第五步：检查Oracle数据库初始化

如果您的集群对任何数据库使用Oracle，在从CDH 5升级到CDH 6之前，使用以下SQL查询检查Oracle数据库中兼容的初始化参数的值:

SELECT name, value FROM v$parameter WHERE name = 'compatible'

默认值是12.2.0。如果参数有不同的值，可以将其设置为默认值，如Oracle数据库升级指南所示。

请注意

在将兼容初始化参数重置为默认值之前，请确保考虑此更改对系统的影响。

第六步：下载及派发包裹

1. 登录到Cloudera Manager管理控制台。

2. 单击主机>包裹。将显示包裹页面。

3. 使用以下远程包裹存储库URL更新CDH的包裹存储库:演示如何使用

4. 如果您的集群安装了GPLEXTRAS，请使用以下远程包裹存储库URL更新GPLEXTRAS包的版本以匹配CDH版本:

   https://archive.cloudera.com/gplextras6/6.2.1/parcels/
   

第七步：运行升级集群向导

1. 如果您正在使用packages，或者没有从包裹页面选择升级，您可以从Home>Status选项卡进入升级CDH页面。单击集群名称旁边，然后选择升级集群。

   选择以前下载/分发的CDH版本。如果没有预先列出符合条件的CDH包裹，或者您想升级到不同版本的CDH:如果您以前使用包，并且想切换到使用包裹，请选择Use packages。

2. Cloudera Manager 5.15及以上版本:

3. 你有一个与现有CDH版本兼容的包，升级向导可能会显示这个包与新的CDH版本冲突的消息。

   • 在继续之前，配置并下载此包的新版本。

• 单击再次运行所有检查按钮。
  • 选择自动解决冲突的选项。
  • Cloudera管理器会使旧版本的数据包失效，激活新版本，并验证所有主机是否安装了正确的软件。

4. 点击继续

显示“选择升级过程”屏幕。从以下选项中选择升级过程:

• 全集群重启

  Cloudera Manager执行所有服务升级并重启集群。

• 手动升级

  Cloudera Manager将集群配置为指定的CDH版本，但不执行升级或服务重启。

  手动升级是困难的，而且只对高级用户。手动升级允许您选择性地停止和重新启动服务，以防止或减轻无法滚动重启的服务或集群的停机时间。

要执行手动升级:有关所需步骤，请参阅在升级失败后手动升级CDH。

5. 单击继续。

   升级集群屏幕显示向导在关闭所有服务、激活新包裹、升级服务、部署客户端配置文件和重启服务时运行的命令的结果。

   如果其中任何一个步骤失败，请纠正所报告的错误并单击Resume按钮。Cloudera管理器将跳过已经成功重启的角色。或者，回到主页面>状态选项卡，然后在升级失败后手动执行升级CDH中的步骤。

   通知：

   如果Cloudera管理器在升级CDH时检测到一个故障，Cloudera管理器会显示一个对话框，在那里你可以创建一个诊断包发送给Cloudera支持，这样他们可以帮助你从故障中恢复。集群名称和持续时间字段是预先填充的，以捕获正确的数据。

6. 点击继续

   如果您的集群以前是使用packages安装或升级的，向导可能指示某些服务无法启动，因为它们的包不可用。下载所需parcels:

• 在另一个浏览器标签页，打开Cloudera Manager管理控制台。

• 选择主机>包裹。

• 找到包含丢失包裹的行，单击按钮下载、分发，然后激活包裹。

• 返回到升级向导并单击Resume按钮。

• 升级向导继续升级集群。

7. 单击完成返回主页。

第八步：删除以前的CDH版本包并刷新符号链接

[CDH维护发布升级不需要。]

如果以前的CDH安装是使用packages完成的，请在安装parcels的所有主机上删除这些packages并刷新符号链接，以便客户机能够运行新的软件版本。

如果您以前安装或升级使用的parcels，请跳过此步骤。

1. 如果您的Hue服务使用嵌入式SQLite数据库，请将/var/lib/ hueb /desktop.db备份到一个不是/var/lib/hue的位置，因为这个目录会在包被删除时被删除。

2. 在每个主机上卸载CDH包:

   Not including Impala and Search

   • RHEL / CentOS

     sudo yum remove bigtop-utils bigtop-jsvc bigtop-tomcat 'hue-*' sqoop2-client

   • SLES

     sudo zypper remove bigtop-utils bigtop-jsvc bigtop-tomcat 'hue-*' sqoop2-client

   • Debian / Ubuntu

     sudo apt-get purge bigtop-utils bigtop-jsvc bigtop-tomcat 'hue-*' sqoop2-client

   Including Impala and Search

   • RHEL / CentOS

     sudo yum remove 'bigtop-*' 'hue-*' impala-shell solr-server sqoop2-client hbase-solr-doc avro-libs crunch-doc avro-doc solr-doc

   • SLES

     sudo zypper remove 'bigtop-*' 'hue-*' impala-shell solr-server sqoop2-client hbase-solr-doc avro-libs crunch-doc avro-doc solr-doc

   • Debian / Ubuntu

     sudo apt-get purge 'bigtop-*' 'hue-*' impala-shell solr-server sqoop2-client hbase-solr-doc avro-libs crunch-doc avro-doc solr-doc

3. 重新启动所有Cloudera Manager Agents，强制更新符号链接，以指向每个主机上新安装的组件。

4. 如果你的Hue服务使用内嵌的SQLite数据库，恢复你备份的数据库:

   • 停止Hue服务。

   • 将备份从临时位置复制到新创建的Hue数据库目录/var/lib/hue.

   • 启动Hue服务。

第九步：完成HDFS的升级

要确定是否可以完成升级，请运行重要的工作负载并确保它们成功。在完成升级之后，不使用备份就不能回滚到HDFS的前一个版本。确认您已经准备好完成升级可能会花费很长时间。

确保你有足够的空闲磁盘空间，记住以下行为一直持续到升级完成:

• 删除文件不会释放磁盘空间。
• 使用平衡器会导致复制所有已移动的副本。
• 表示NameNode元数据的所有磁盘上的数据都被保留，这可能会使NameNode和JournalNode磁盘上所需的空间增加一倍以上。

1. 转到HDFS服务。
2. 单击实例选项卡。
3. 单击NameNode实例，将显示NameNode实例页面。
4. 选择Actions > 最终化元数据升级并单击最终化元数据升级进行确认。

第十步：对于带有Oracle数据库的Sentry，添加AUTHZ_PATH。AUTHZ_OBJ_ID指数

如果集群使用Sentry和Oracle数据库，则必须手动在AUTHZ_PATH上添加索引。AUTHZ_OBJ_ID列(如果它不存在)。手动添加索引可以减少哨兵获取完整的HDFS同步快照所需的时间。使用以下命令添加索引:

CREATE INDEX "AUTHZ_PATH_FK_IDX" ON "AUTHZ_PATH" ("AUTHZ_OBJ_ID");

第十一步：退出维护模式

如果您在此升级期间进入了维护模式，请退出维护模式。

在Home > Status选项卡上，单击集群名称旁边的选项卡，然后选择退出维护模式。

升级失败后手动升级CDH

重要提示

只有当升级向导报告失败时，或者如果您从CDH升级向导中选择了手动升级(手动升级选项仅用于较小的或维护升级)，才执行本节中的步骤。手动升级允许您选择性地停止和重新启动服务，以防止或减轻无法滚动重启的服务或集群的停机时间。
下面的所有步骤都假设CDH的启动版本至少是5.13.0，或者Cloudera Runtime的启动版本至少是7.0.3，因为这些是Cloudera Manager 7.1支持的最低版本。

下面的步骤应该大致按照列出的顺序执行，并且只有在配置了服务后才应该执行。

第一步：升级Ranger数据库并应用补丁

升级的需求：

• 7.0.x to Cloudera Runtime 7.1.1 or higher

1. 选择Ranger服务。
2. 选择Actions >升级Ranger数据库并应用补丁，单击升级Ranger数据库并应用补丁确认

第二步：设置Ranger管理的组件

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择Ranger服务。
2. 选择“动作>”设置Ranger管理组件，然后单击“设置Ranger管理组件”确认。

第三步：启动Ranger

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择Ranger服务。
2. 启动Ranger服务

第四步：设置Ranger插件服务

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择Ranger服务。
2. 选择Actions > Setup Ranger Plugin Service并单击Setup Ranger Plugin Service确认。

第五步：启动Kudu

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择Kudu服务。
2. 启动kudu服务

第六步：启动Zookeeper

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择Zookeeper服务。
2. 启动Zookeeper服务

第七步：升级HDFS元数据

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher
• CDH 5.x to 6.0.0 or higher

选择HDFS服务。

选择Actions > 升级HDFS元数据，单击升级HDFS元数据确认。

第八步：启动HFDS

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择HDFS服务。
2. 启动HDFS服务

第九步：启动YARN QueueManager

升级的需求：.

• Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. 转到QueueManager服务。
2. 选择Actions > Start。

第十步：导入Sentry的Polices到Ranger

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择HDFS服务
2. 选择Actions > Import Sentry policy into Ranger，点击Import Sentry policy into Ranger确认。

第十一步：启动HBASE

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择HBASE服务。
2. 启动HBASE服务

第十二步：启动YARN QueueManager

升级的需求：.

• Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. 转到QueueManager服务。
2. 选择Actions > Start。

第十三步：清理NodeManager的恢复目录(YARN)

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择YARN服务。
2. 选择Actions > Clean NodeManager 恢复目录并单击Clean NodeManager 恢复目录进行确认。

第十四步：重制YARN在Zookeeper nodes的ACLs

升级的需求：

• CDH 5.x to 7.1.1 or higher
• 如果YARN在高可用性模式下运行或，资源管理器组(例如:ResourceManager默认组)启用ResourceManager恢复(YARN . ResourceManager .recovery.enabled)。

1. SSH到运行ZooKeeper服务器的集群节点。

2. 使用以下参数运行zk-client.sh脚本:

   • /opt/cloudera/cm-agent/service/zookeeper/zk-client.sh removeYarnACLs /yarn-leader-election，/rmstore

   • 其中zkQuorum (url:port)和zkAuth(用户名:密码)属性值来自yarn-site.xml，它位于: /etc/hadoop/conf.cloudera.YARN-1/yarn-site.xml

• 
    hadoop.registry.zk.quorum
    url:port
  
  

• 
    yarn.resourcemanager.zk-auth
    digest:username:password
  
  

• 注意只需要:yarn.resourcemanager.zk-auth 属性的username:password字符串。需要删除zk-client.sh 参数的zk-auth属性的值、身份验证方法(digest:)。

第十五步：安装YARN MapReduce框架jar

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择YARN服务。
2. 选择Actions > 安装YARN MapReduce框架jar并单击安装YARN MapReduce框架jar进行确认。

第十六步：启动YARN

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择YARN服务。
2. 启动YARN

第十七步：部署客户端配置文件

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 在主页上，单击集群名称右侧并选择部署客户端配置
2. 单击出现的确认弹出窗口中的部署客户端配置按钮。

第十八步：重新初始化Solr状态以进行升级确认

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择SOLR服务。
2. 选择Actions > Reinitialize Solr State for Upgrade并单击Reinitialize Solr State for Upgrade确认。

第十九步：引导Solr配置

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择SOLR服务。
2. 选择Actions Bootstrap Solr配置并单击Bootstrap Solr配置进行确认。。

第二十步：启动Solr

升级的需求：

• CDH 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. 选择SOLR服务。
2. 启动SOLR服务

第二十一步：引导Solr集合

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择SOLR服务。

2. 选择Actions Bootstrap Solr Collections并单击Bootstrap Solr Collections进行确认

第二十二步：创建HDFS主目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 转到基础设施SOLR服务。

2. 选择Actions > Create HDFS Home Dir并单击Create HDFS Home Dir确认。

第二十三步：创建Ranger插件审计目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选着Solr服务.
2. 选着 Actions > Create Ranger Kafka Plugin Audit Directory and click Create Ranger Kafka Plugin Audit Directory to confirm.

第二十四步：启动基础设施Solr

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. 选择基础设施Solr
2. Select Actions > Start.

第二十五步：启动HBase

升级的需求：

• Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the HBASE service.
2. Select Actions > Start.

第二十六步：启动Kafka

升级的需求：

• CDH 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the KAFKA service.
2. Select Actions > Start.

第二十七步：创建Ranger Kafka插件审计目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the KAFKA service.
2. Select Actions > Create Ranger Kafka Plugin Audit Directory and click Create Ranger Kafka Plugin Audit Directory to confirm.

第二十八步：为Atlas创建HBase表

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the ATLAS service.
2. Select Actions > Create HBase tables for Atlas and click Create HBase tables for Atlas to confirm.

第二十九步：启动Atlas

升级的需求：

• CDH 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the ATLAS service.
2. Select Actions > Start.

第三十步：创建Ranger Atlas插件审计目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the ATLAS service.
2. Select Actions > Create Ranger Atlas Plugin Audit Directory and click Create Ranger Atlas Plugin Audit Directory to confirm.

第三十一步：启动Phoenix

升级的需求：

• CDH Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the PHOENIX service.
2. Select Actions > Start.

第三十二步：安装MapReduce框架jar

升级的需求：

• Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the YARN service.
2. Select Actions > Install YARN MapReduce Framework JARs and click Install YARN MapReduce Framework JARs to confirm.

第三十三步：启动YARN

升级的需求：

• Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the YARN service.
2. Select Actions > Start.

第三十四步：部署客户端配置文件

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. On the Home page, click to the right of the cluster name and select Deploy Client Configuration.
2. Click the Deploy Client Configuration button in the confirmation pop-up that appears.

第三十五步：升级Hive Metastore数据库

警告警告！！！

如果不完成此步骤，升级将失败。

升级的需求：

• CDH 5.x to 6.0.0 or higher

1. Go to the Hive service.
2. If the Hive service is running, stop it:
   1. Select Actions > Stop and click Stop to confirm.
3. Select Actions > Upgrade Hive Metastore Database Schema and click Upgrade Hive Metastore Database Schema to confirm.
4. 如果你有多个Hive实例，对每个metastore数据库执行升级。
5. Select Actions > Validate Hive Metastore Schema and click Validate Hive Metastore Schema to check that the schema is now valid.

第三十六步：启动Hive

升级的需求：

• 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the Hive service.
2. Select Actions > Start.

第三十七步：创建Hive Warehouse目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the HIVE service.
2. Select Actions > Create Hive Warehouse Directory and click Create Hive Warehouse Directory to confirm.

第三十八步：创建Hive Warehouse外部目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the HIVE service.
2. Select Actions > Create Hive Warehouse External Directory and click Create Hive Warehouse External Directory to confirm.

第三十九步：创建Hive系统数据库

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the HIVE service.
2. Select Actions > Create Hive Sys database and click Create Hive Sys database to confirm.

第四十步：创建Ranger插件审计目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the HIVE service.
2. Select Actions > Create Ranger Plugin Audit Directory and click Create Ranger Plugin Audit Directory to confirm.

第四十一步：启动Impala

升级的需求：

• CDH 5.x to 6.0.0 or higher

1. Go to the Impala service.
2. Select Actions > Start.

第四十二步：创建Ranger插件审计目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the Impala service.
2. Select Actions > Create Ranger Plugin Audit Directory and click Create Ranger Plugin Audit Directory to confirm.

第四十三步：创建Spark驱动程序日志目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the SPARK_ON_YARN service.
2. Select Actions > Create Spark Driver Log Dir and click Create Spark Driver Log Dir to confirm.

第四十四步：启动Spark

升级的需求：

• CDH 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the SPARK_ON_YARN service.
2. Select Actions > Start.

第四十五步：启动Livy

升级的需求：

• Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the LIVY service.
2. Select Actions > Start.

第四十六步：升级Oozie数据库模式

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the OOZIE service.

2. If the OOZIE service is running, stop it:

   Select Actions > Stop and click Stop to confirm.

3. Select Actions > Upgrade Oozie Database Schema and click Upgrade Oozie Database Schema to confirm.

第四十七步：升级Oozie 共享库

升级的需求：

• CDH 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the Oozie service.

2. If the OOZIE service is stopped, start it:

   Select Actions > Start and click Start to confirm.

3. Select Actions > Install Oozie SharedLib and click Install Oozie SharedLib to confirm.

第四十八步：启动 Oozie?

第四十九步：上传TEZtar文件到HDFS

升级的需求：

• CDH 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the TEZ service.
2. Select Actions > Upload Tez tar file to HDFS and click Upload Tez tar file to HDFS to confirm.

第五十步：迁移用于CDP升级的Hive表

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the HIVE_ON_TEZ service.
2. Select Actions > Migrate Hive tables for CDP upgrade and click Migrate Hive tables for CDP upgrade to confirm.

第五十一步：创建Ranger插件审计目录

升级的需求：

• CDH 5.x to Cloudera Runtime 7.1.1 or higher

1. Go to the Hive-on-Tez service.
2. Select Actions > Create Ranger Plugin Audit Directory and click Create Ranger Plugin Audit Directory to confirm.

第五十二步：启动Hive on Tez

升级的需求：

• CDH 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the Hive-on-Tez service.
2. Select Actions > Start.

第五十三步：启动Hue

升级的需求：

• CDH 5.x and Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the HUE service.
2. Select Actions > Start.

第五十四步：启动 DAS

升级的需求：

• Cloudera Runtime 7.0.x to Cloudera Runtime 7.1.1 or higher

1. Go to the DAS service.
2. Select Actions > Start.

第五十五步：启动启动其余的集群服务

1. Use rolling restart or full restart.
2. Ensure that all services are started or restarted. You can use Cloudera Manager to start the cluster, or you can restart the services individually. The Cloudera Manager Home page indicates which services have stale configurations and require restarting.
3. To start or restart the cluster:
   1. On the Home > Status page, click the down arrow to the right of the cluster name and select Start or Restart.
   2. Click Start that appears in the next screen to confirm. The Command Details window shows the progress of starting services.
   3. When All services successfully started appears, the task is complete and you can close the Command Details window.

第五十六步：验证Hive Metastore数据库模式

警告警告！！！

如果不完成此步骤，升级将失败。

升级的需求：

• CDH 5.x to 6.0.0 or higher

1. Select Actions > Validate Hive Metastore Schema and click Validate Hive Metastore Schema to confirm.
2. If you have multiple instances of Hive, perform the validation on each metastore database.
3. Select Actions > Validate Hive Metastore Schema and click Validate Hive Metastore Schema to check that the schema is now valid.

第五十七步：测试集群并最终确定HDFS元数据

To determine if you can finalize the upgrade, run important workloads and ensure that they are successful. After you have finalized the upgrade, you cannot roll back to a previous version of HDFS without using backups. Verifying that you are ready to finalize the upgrade can take a long time.

When you are ready to finalize the upgrade, do the following:

• 1. Go to the HDFS service.

  2. Click the Instances tab.

  3. Click the link for the NameNode instance.If you have enabled high availability for HDFS, click the link labeled NameNode (Active).

     The NameNode instance page displays.

  4. Select Actions > 最终化元数据升级 and click 最终化元数据升级 to confirm.

CDH升级的故障排除

“Access denied” in install or update wizard

在为活动监视器或报告管理器配置数据库期间，安装或更新向导中的“访问被拒绝”。

可能的原因

没有正确设置主机名映射或权限。

可能的解决方案

有关主机名配置，请参见配置网络名。

对于权限，请确保在向导中输入的值与配置数据库时使用的值匹配。您在向导中输入的作为数据库主机名的值必须与您在配置数据库时为主机名(如果有的话)输入的值匹配。

例如，如果您在创建数据库时输入了以下内容

grant all on activity_monitor.* TO 'amon_user'@'myhost1.myco.com' IDENTIFIED BY 'amon_password';

在这里输入的数据库主机名的值必须是myhost1.myco.com。如果没有指定主机，或使用通配符允许从任何主机访问，则可以输入完全限定域名(FQDN)或本地主机。例如，如果您输入

grant all on activity_monitor.* TO 'amon_user'@'%' IDENTIFIED BY 'amon_password';

为数据库主机名输入的值可以是FQDN或本地主机。

没有出现集群主机

在安装或更新向导中单击查找主机时，一些集群主机不会出现。

可能的原因

您可能有网络连接问题

可能的解决方法

• 确保所有集群主机都打开了SSH端口22。
• 检查导致连接丢失的其他常见原因，如防火墙和来自SELinux的干扰。

升级后无法启动服务

您升级了Cloudera管理器服务器，但现在无法启动服务。

可能的原因

您可能有不匹配的Cloudera Manager服务器和代理版本。

可能的解决方法

确保您已经升级了所有主机上的Cloudera Manager代理。(代理的前一个版本会随着服务器的新版本而心跳，但是不能用这个组合启动HDFS和MapReduce。)

HDFS DN无法启动

升级后，HDFS DN启动失败，异常:

Exception in secureMainjava.lang.RuntimeException: Cannot start datanode because the configured max locked memory size (dfs.datanode.max.locked.memory) of 4294967296 bytes is more than the datanode's available RLIMIT_MEMLOCK ulimit of 65536 bytes.

可能的原因

HDFS缓存在cdh5或更高版本中是默认启用的，需要Cloudera Manager代理提供新的memlock功能。

可能的解决方法

执行以下操作:

1. 停止所有CDH和托管服务。
2. 在使用Cloudera Manager代理的所有主机上，硬重启代理。在执行此步骤之前，通过读取Cloudera Manager代理，确保您理解了hard_restart命令的语义。

RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

sudo systemctl stop supervisord
sudo systemctl start cloudera-scm-agent

RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

sudo service cloudera-scm-agent hard_restart

3. 启动所有服务。

Cloudera服务无法启动

cloudera服务无法启动。

可能的原因

Java可能没有安装，也可能安装在自定义位置。

可能的解决方法

有关解决此问题的更多信息，请参见配置自定义Java主位置。

升级到CDH 5.8.0或CDH 5.8.1时使用Flume Kafka客户端

由于CDH 5.8 Flume Kafka客户端从ZooKeeper更改为Kafka的偏移存储，在升级到CDH 5.8.0或CDH 5.8.1期间，数据可能不会被Flume代理使用，或者可能被复制(如果Kafka .auto.offset.reset=smallest)。要防止这种情况发生，请在升级系统之前执行以下步骤。

重要的

这个问题已经在CDH 5.8.2及更高版本中得到修复。如果您正在升级到CDH 5.8.2或更高版本，则不需要执行此过程。有关更多信息，请参见CDK已知问题。

升级过程基于这个配置示例:

tier1.sources  = source1
        tier1.channels = channel1
        tier1.sinks = sink1

        tier1.sources.source1.type = org.apache.flume.source.kafka.KafkaSource
        tier1.sources.source1.zookeeperConnect = zkhost:2181
        tier1.sources.source1.topic = flumetopic
        tier1.sources.source1.groupId = flume
        tier1.sources.source1.channels = channel1
        tier1.sources.source1.interceptors = i1 i2
        tier1.sources.source1.interceptors.i1.type = timestamp
        tier1.sources.source1.interceptors.i2.type = host
        tier1.sources.source1.kafka.consumer.timeout.ms = 100

        tier1.channels.channel1.type = org.apache.flume.channel.kafka.KafkaChannel
        tier1.channels.channel1.brokerList=broker1:9092,broker2:9092
        tier1.channels.channel1.zookeeperConnect=zkhost:2181
        tier1.channels.channel1.topic=flumechannel1
        tier1.channels.channel1.groupId = flumechannel
        tier1.channels.channel1.capacity = 10000
        tier1.channels.channel1.transactionCapacity = 1000

        tier1.sinks.sink1.type = hdfs
        tier1.sinks.sink1.hdfs.path = /tmp/kafka/%{topic}/
        tier1.sinks.sink1.hdfs.filePrefix = %{host}-
        tier1.sinks.sink1.hdfs.rollInterval = 60
        tier1.sinks.sink1.hdfs.rollSize = 0
        tier1.sinks.sink1.hdfs.rollCount = 0
        tier1.sinks.sink1.hdfs.fileType = DataStream
        tier1.sinks.sink1.channel = channel1
        tier1.sinks.sink1.hdfs.kerberosKeytab = $KERBEROS_KEYTAB
        tier1.sinks.sink1.hdfs.kerberosPrincipal = $KERBEROS_PRINCIPAL

执行以下步骤升级CDH。

1. 如果您使用的版本低于CDH 5.7，请首先升级到CDH 5.7。如果由于某些原因您不能升级到CDH 5.7，请联系您的Cloudera销售工程师以获得帮助，或提交一个支持案例，说明您正在升级的特定版本。

2. 将以下部分添加到Flume 配置的源和通道中

   # Added for source upgrade compatibility
               tier1.sources.source1.kafka.bootstrap.servers = broker1:9092,broker2:9092
               tier1.sources.source1.kafka.offsets.storage = kafka
               tier1.sources.source1.kafka.dual.commit.enabled = true
               tier1.sources.source1.kafka.consumer.group.id = flume
               tier1.sources.source1.kafka.topics = flumetopic
   
               # Added for channel upgrade compatability
               tier1.channels.channel1.kafka.topic = flumechannel1
               tier1.channels.channel1.kafka.bootstrap.servers = broker1:9092,broker2:9092
               tier1.channels.channel1.kafka.consumer.group.id = flumechannel
               tier1.channels.channel1.kafka.offsets.storage = kafka
               tier1.channels.channel1.kafka.dual.commit.enabled = true
   

3. 重新启动(或滚动重新启动)Flume 代理。这个开关offsets.storage到kafka。但是会不断更新Kafka和ZooKeeper偏移量，因为dul .commit.enabled属性被设置为true。确认Kafka消息正在通过Flume服务器。只有在使用新消息时才会更新偏移量，因此Flume代理至少需要使用一条Kafka消息，或者通过Flume通道传递一个事件。使用以下命令来验证Flume是否正确地更新了Kafka中的偏移量(使用egrep命令匹配正确的主题名称:在这个例子中，flumetopic和flumechannel)

   echo "exclude.internal.topics=false" > /tmp/consumer.config
               kafka-console-consumer --consumer.config /tmp/consumer.config
               --formatter "kafka.coordinator.GroupMetadataManager\$OffsetsMessageFormatter"
               --zookeeper zkhost:2181 --topic __consumer_offsets  |egrep -e "flumetopic|flumechannel1"
   

   输出应该类似如下，并显示flume源和/或channel主题偏移量正在增加:

   [flume,flumetopic,0]::[OffsetMetadata[70,cf9e5630-214e-4689-9869-5e077c936ffb],CommitTime 1469827951129,ExpirationTime 1469914351129]
               [flumechannel,flumechannel1,0]::[OffsetMetadata[61,875e7a82-1c22-43be-acaa-eb4d63e7f71e],CommitTime 1469827951128,ExpirationTime 1469914351128]
               [flumechannel,flumechannel1,0]::[OffsetMetadata[62,66bda888-0a70-4a02-a286-7e2e7d14050d],CommitTime 1469827951131,ExpirationTime 1469914351131]
   

   4.执行到CDH 5.8.0或CDH 5.8.1的升级。在此过程中，Flume 代理将重新启动。Flume继续消耗它停止的源主题，而sink继续消耗它们停止的Kafka通道。升级后，从Flume .conf中删除以下不推荐的属性，因为它们不再在CDH 5.8.0或更高版本中使用:

   tier1.sources.source1.zookeeperConnect = zkhost:2181
               tier1.sources.source1.topic = flumetopic
               tier1.sources.source1.groupId = flume
   
               tier1.channels.channel1.zookeeperConnect=zkhost:2181
               tier1.channels.channel1.topic=flumechannel1
               tier1.channels.channel1.groupId = flumechannel
   

回滚cdh5到cdh6升级

您可以回滚从cdh5到cdh6的升级。回滚将CDH集群恢复到升级之前的状态，包括Kerberos和TLS/SSL配置。

重要的

升级后创建的任何数据都会丢失。

在典型的升级中，首先要从版本5升级Cloudera Manager到版本6.x，然后使用Cloudera Manager 6的升级版本将cdh5升级到cdh6。(请参阅升级集群。)如果希望回滚此升级，请按照以下步骤将集群回滚到升级之前的状态。

只有在HDFS升级尚未完成时，才可以在升级到cdh6后回滚到cdh5。回滚将CDH集群恢复到升级之前的状态，包括Kerberos和TLS/SSL配置。

重要提示

按照本主题中给出的顺序执行所有步骤。Cloudera建议在开始备份过程之前阅读备份和回滚步骤。您可能需要创建一个详细的计划来帮助您预测潜在的问题。

重要提示

这些回滚步骤依赖于在升级Cloudera Manager和CDH之前执行的完整备份。参见备份Cloudera管理器和备份集群。

对于需要还原目录内容的步骤，请在将备份的文件复制到该目录之前清除该目录的内容。如果您未能做到这一点，那么如果您在回滚之后再次尝试升级，来自原始升级的工件可能会导致问题。

1.说明回滚的局限性

回滚过程有以下限制:

• HDFS–如果你已经完成了HDFS升级，你不能回滚你的集群。
• 配置更改–在回滚Cloudera Manager后，不会保留配置更改，包括升级后添加的新服务或角色。Cloudera建议，在完成HDFS升级、不再需要回滚升级选项之前，不要修改配置或添加新的服务和角色。
• HBase–如果集群配置为使用HBase replication，升级后写入HBase的数据可能不会在开始回滚时复制到对等节点。本主题不描述如何确定哪个对等点(如果有的话)拥有复制的数据，以及如何回滚该数据。有关HBase复制的更多信息，请参见HBase复制。
• Sqoop 1 -由于在Sqoop metastore逻辑中引入的变化，CDH 6创建的metastore数据库。早期版本不能使用x版本的Sqoop。
• Sqoop2——正如升级过程中所描述的，Sqoop2必须在升级过程之前停止并删除，因此在回滚之后将不可用。
• Kafka --一旦Kafka的日志格式和协议版本配置(inter.broker.protocol.version 和log.message.format.version属性)设置为新版本(或留空，这意味着使用最新的版本)，Kafka回滚是不可能的。

2.停止集群

1. 在Home > Status选项卡上，单击集群名称的右侧并选择Stop。
2. 在确认屏幕中单击Stop。命令详细信息窗口显示停止服务的进度。
3. 当所有服务成功停止时，任务完成，您可以关闭命令详细信息窗口

3.(包裹)降级软件

仅当您的集群使用Cloudera包裹升级时，请遵循这些步骤。

1. 登录到Cloudera Manager管理控制台。

2. 选择主机>包裹。

   一个包裹列表显示。

3. 找到CDH 5包裹并单击Activate。(这将自动使CDH 6包裹失效。)有关更多信息，请参见激活包裹。如果包裹不可用，使用下载按钮下载包裹。

4. 如果在集群中包含任何其他组件，如Search或Impala，请单击这些包裹的Activate

重要的

不要启动任何服务。(选择“只激活”选项)

如果意外重启服务，请在继续之前停止集群。

4.停止CM

1. 停止Cloudera管理服务

2. 停止Cloudera管理器服务器

   RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

   sudo systemctl stop cloudera-scm-server
   

   RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

   sudo service cloudera-scm-server stop
   

3. 硬阻止CM代理。在所有主机上运行以下命令:

   RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

   sudo systemctl stop cloudera-scm-supervisord.service
   

   RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

   sudo service cloudera-scm-agent hard_stop
   

5.(软件包)降级软件

仅当您的集群使用包升级时，请遵循这些步骤。

运行Package命令

1. 作为集群中所有主机的特权用户登录。

2. 备份存储库目录。您可以使用以下命令创建一个顶级备份目录和一个环境变量来引用该目录。您还可以在以下备份命令中替换另一个目录路径:

   export CM_BACKUP_DIR="`date +%F`-CM"
   mkdir -p $CM_BACKUP_DIR
   

RHEL / CentOS

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

SLES

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

Debian / Ubuntu

sudo -E tar -cf $CM_BACKUP_DIR/repository.tar /etc/apt/sources.list.d

3. 从升级到CDH 6之前的备份中恢复cdh5存储库目录。例如:

tar -xf CM6CDH5/repository.tar -C CM6CDH5/

RHEL

rm -rf /etc/yum.repos.d/*
cp -rp CM6CDH5/etc/yum.repos.d/* /etc/yum.repos.d/

SLES

rm -rf /etc/zypp/repos.d
cp -rp CM6CDH5/etc/zypp/repos.d/* /etc/zypp/repos.d/

Debian / Ubuntu

rm -rf /etc/apt/sources.list.d/*
cp -rp CM6CDH5/etc/apt/sources.list.d/* /etc/apt/sources.list.d/

4. 运行以下命令卸载cdh6并重新安装cdh5包

   RHEL / CentOS

   sudo yum clean 
   
   sudo yum remove avro-tools flume-ng avro-libs hadoop-hdfs-fuse hadoop-hdfs-nfs3 hadoop-httpfs hadoop-kms hbase-solr hive-hbase hive-webhcat hue impala impala-shell kafka kite kudu oozie pig search sentry sentry-hdfs-plugin solr-crunch solr-mapreduce spark-core spark-python sqoop zookeeper parquet hbase solr
   
   sudo yum -y install --setopt=timeout=180 bigtop-utils solr-doc oozie-client hue-spark kite crunch-doc sqoop hue-rdbms hbase-solr hue-plugins pig spark-python oozie hadoop-kms bigtop-tomcat hbase hue-sqoop sqoop2 spark-core hadoop-mapreduce avro-tools hadoop-hdfs avro-libs hadoop sqoop2-client mahout avro-doc hue-impala hbase-solr-doc hive-jdbc crunch zookeeper hadoop-hdfs-nfs3 bigtop-jsvc hue-common hue-hbase hadoop-client hive-webhcat parquet-format hue-beeswax keytrustee-keyprovider hue-pig llama hive-hcatalog kudu kafka solr hue-search hive-hbase search solr-crunch flume-ng hadoop-httpfs hue-security sentry hive sentry-hdfs-plugin hadoop-yarn hadoop-hdfs-fuse parquet hadoop-0.20-mapreduce impala-shell impala hue-zookeeper solr-mapreduce
   

   SLES

   sudo zypper clean --all
   
   sudo zypper remove avro-tools flume-ng avro-libs hadoop-hdfs-fuse hadoop-hdfs-nfs3 hadoop-httpfs hadoop-kms hbase-solr hive-hbase hive-webhcat hue impala impala-shell kafka kite kudu oozie pig search sentry sentry-hdfs-plugin solr-crunch solr-mapreduce spark-core spark-python sqoop zookeeper parquet hbase solr
   
   sudo zypper install solr-doc oozie-client hue-spark kite crunch-doc sqoop hue-rdbms hbase-solr hue-plugins pig spark-python oozie hadoop-kms bigtop-tomcat hbase hue-sqoop sqoop2 spark-core hadoop-mapreduce avro-tools hadoop-hdfs avro-libs hadoop sqoop2-client mahout avro-doc hue-impala hbase-solr-doc hive-jdbc crunch zookeeper hadoop-hdfs-nfs3 bigtop-jsvc hue-common hue-hbase hadoop-client hive-webhcat parquet-format hue-beeswax keytrustee-keyprovider hue-pig llama hive-hcatalog kudu kafka solr hue-search hive-hbase search solr-crunch flume-ng hadoop-httpfs hue-security sentry hive sentry-hdfs-plugin hadoop-yarn hadoop-hdfs-fuse parquet hadoop-0.20-mapreduce impala-shell impala hue-zookeeper solr-mapreduce
   

   Debian / Ubuntu

   sudo apt-get update
   sudo apt-get remove avro-tools flume-ng avro-libs hadoop-hdfs-fuse hadoop-hdfs-nfs3 hadoop-httpfs hadoop-kms hbase-solr hive-hbase hive-webhcat hue impala impala-shell kafka kite kudu oozie pig search sentry sentry-hdfs-plugin solr-crunch solr-mapreduce spark-core spark-python sqoop zookeeper parquet hbase solr
   
   sudo apt-get update
   sudo apt-get install solr-doc oozie-client hue-spark kite crunch-doc sqoop hue-rdbms hbase-solr hue-plugins pig spark-python oozie hadoop-kms bigtop-tomcat hbase hue-sqoop sqoop2 spark-core hadoop-mapreduce avro-tools hadoop-hdfs avro-libs hadoop sqoop2-client mahout avro-doc hue-impala hbase-solr-doc hive-jdbc crunch zookeeper hadoop-hdfs-nfs3 bigtop-jsvc hue-common hue-hbase hadoop-client hive-webhcat parquet-format hue-beeswax keytrustee-keyprovider hue-pig llama hive-hcatalog kudu kafka solr hue-search hive-hbase search solr-crunch flume-ng hadoop-httpfs hue-security sentry hive sentry-hdfs-plugin hadoop-yarn hadoop-hdfs-fuse parquet hadoop-0.20-mapreduce impala-shell impala hue-zookeeper solr-mapreduce
   

6.恢复Cloudera管理器数据库

从集群升级到CDH 6之前的Cloudera Manager备份中恢复Cloudera Manager数据库。请参阅数据库供应商提供的过程。

7. 恢复Cloudera管理器服务器

使用升级前的CDH备份来恢复Cloudera Manager服务器的文件和目录。按照以下步骤替换cm6_cdh5备份目录的路径:

1. 在配置运行事件服务器角色的主机上，从CM 6/CDH 5备份恢复事件服务器目录。

   rm -rf /var/lib/cloudera-scm-eventserver/*
   cp -rp /var/lib/cloudera-scm-eventserver_cm6_cdh5/* /var/lib/cloudera-scm-eventserver/
   

2. 删除代理运行时状态。在所有主机上运行以下命令:

   rm -rf /var/run/cloudera-scm-agent /var/lib/cloudera-scm-agent/response.avro
   

   这个命令可能会返回类似于: rm: cannot remove ‘/var/run/cloudera-scm-agent/process’: Device or resource busy. 您可以忽略此消息。

3. 在运行服务监视器的主机上，恢复服务监视器目录

   rm -rf /var/lib/cloudera-service-monitor/*
   cp -rp /var/lib/cloudera-service-monitor_cm6_cdh5/* /var/lib/cloudera-service-monitor/
   

4. 在运行主机监视器的主机上，恢复主机监视器目录:

   rm -rf /var/lib/cloudera-host-monitor/*
   cp -rp /var/lib/cloudera-host-monitor_cm6_cdh5/* /var/lib/cloudera-host-monitor/
   

5. 从CM 6/CDH 5备份中恢复Cloudera导航器存储目录。

   rm -rf /var/lib/cloudera-scm-navigator/*
   cp -rp /var/lib/cloudera-scm-navigator_cm6_cdh5/* /var/lib/cloudera-scm-navigator/
   

8.启动CM

1. 启动Cloudera Manager Server

   RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

   sudo systemctl start cloudera-scm-server
   

   如果Cloudera管理器服务器在没有错误的情况下启动，则不会显示响应。

   RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

   sudo service cloudera-scm-server start
   

   You should see the following:

   Starting cloudera-scm-server: [ OK ]
   

2. 启动Cloudera Manager Agent

   在所有集群主机上运行以下命令:

   RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

   sudo systemctl start cloudera-scm-agent
   

   如果代理启动时没有错误，则不会显示响应。

   RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

   sudo service cloudera-scm-agent start
   

   You should see the following:

   Starting cloudera-scm-agent: [ OK ]
   

3. 启动 Cloudera Management Service.

9.回滚Zookeeper

1. 使用您在备份cdh5时创建的Zookeeper备份。在每个ZooKeeper服务器上恢复dataDir的内容。这些文件位于ZooKeeper配置中由dataDir属性指定的目录中。默认位置是/var/lib/zookeeper。例如:

   rm -rf /var/lib/zookeeper/*
   cp -rp /var/lib/zookeeper_cm6_cdh5/* /var/lib/zookeeper/
   

2. 确保所有目录和文件的权限与升级前相同。

3. 使用Cloudera管理器启动ZooKeeper。

10.回滚HDFS

在启用高可用性时，不能回滚HDFS。本主题中的回滚过程创建一个没有高可用性的临时配置。无论是否启用了高可用性，请遵循本节中的步骤。

1. 回滚所有日志节点。(仅适用于启用HDFS高可用性的集群)。使用在升级到CDH 6之前备份HDFS时创建的JournalNode备份。

   • 登录到每个Journal Node主机并运行以下命令:

     rm -rf /dfs/jn/ns1/current/*
     cp -rp /dfs/jn/ns1/previous/* /dfs/jn/ns1/current/
     

   • 使用Cloudera管理器启动JournalNodes:

     • 转到HDFS服务。
     • 选择Instances选项卡。
     • 从列表中选择所有的JournalNode角色。
     • 单击选定>开始的操作

2. 回滚所有的namenode。使用升级CDH之前创建的NameNode备份目录(/etc/hadoop/conf.rollback.namenode)在所有NameNode主机上执行以下步骤:

   • (仅启用TLS的集群)在所有NameNode主机(位于临时回滚目录中)上编辑/etc/hadoop/conf.rollback.NameNode/ssl-server.xml文件，并用实际的明文密码更新密钥存储库密码。

     密码的值如下：

     <property>
         <name>ssl.server.keystore.password</name>
         <value>********</value>
       </property>
       <property>
         <name>ssl.server.keystore.keypassword</name>
         <value>********</value>
       </property>
     

     (仅适用于TLS)编辑/etc/hadoop/conf.rollback.namenode/ssl-server.xml文件并删除hadoop.security.credential.provider.path属性。

3. 在所有的NameNode主机上编辑/etc/hadoop/conf.rollback.NameNode/hdfs-site.xml文件，并进行以下更改:

   • 删除cloudera.navigator.client.config属性。

   • 删除dfs.namenode.audit.loggers属性。

   • 更改dfs中的路径。将属性设置为下面示例中所示的值。文件名dfs_all_hosts.txt，可能已经被用户更改。如果是，则替换正确的文件名。

     # Original version of the dfs.hosts property:
     <property>
     <name>dfs.hosts</name>
     <value>/var/run/cloudera-scm-agent/process/63-hdfs-NAMENODE/dfs_all_hosts.txt</value>
     </property>
     

     # New version of the dfs.hosts property:
     <property>
     <name>dfs.hosts</name>
     <value>/etc/hadoop/conf.rollback.namenode/dfs_all_hosts.txt</value>
     </property>
     

   • 编辑/etc/hadoop/conf.rollback.namenode/core-site.xml，并将net.topology.script.file.name属性的值更改为/etc/hadoop/conf.rollback.namenode。例如:

     # Original property
     <property>
     <name>net.topology.script.file.name</name>
     <value>/var/run/cloudera-scm-agent/process/63-hdfs-NAMENODE/topology.py</value>
     </property>
     

     # New property
     <property>
     <name>net.topology.script.file.name</name>
     <value>/etc/hadoop/conf.rollback.namenode/topology.py</value>
     </property>
     

   • 编辑/etc/hadoop/conf.rollback.namenode/topology.py文件，并将MAP_FILE的值更改为/etc/hadoop/conf.rollback.namenode。例如:

     MAP_FILE = '/etc/hadoop/conf.rollback.namenode/topology.map'
     

   • (仅在支持tls的集群)运行以下命令:

     sudo -u hdfs kinit hdfs/<NameNode Host name> -l 7d -kt /etc/hadoop/conf.rollback.namenode/hdfs.keytab
     

   • 运行以下命令:

     sudo -u hdfs hdfs --config /etc/hadoop/conf.rollback.namenode namenode -rollback
     

   • 使用Cloudera管理器重新启动namenode和JournalNodes:

     • 转到HDFS服务。
     • 选择Instances选项卡，然后从列表中选择所有故障转移控制器、NameNode和JournalNode角色。
     • 单击选定的>重启的操作。

4. 回滚的datanode

   使用升级CDH之前创建的DataNode回滚目录(/etc/hadoop/conf.rollback.datanode)在所有DataNode主机上执行以下步骤:

   • (仅启用了TLS的集群)编辑所有DataNode主机(位于临时回滚目录中)上的/etc/hadoop/conf.rollback.dataNode /ssl-server.xml文件，并更新密钥库密码(ssl.server.keystore.password和实际密码的ssl.server.keystore.keypassword)。

     密码的值如下:

     <property>
         <name>ssl.server.keystore.password</name>
         <value>********</value>
       </property>
       <property>
         <name>ssl.server.keystore.keypassword</name>
         <value>********</value>
       </property>
     

   • (TLS only)编辑/etc ./hadoop.conf.rollback.datanode/ssl-server.xml文件并删除hadoop.security.credential.provider.path属性。

   • 编辑/etc/hadoop/conf.rollback.datanode/hdfs-site.xml文件并删除dfs.datanode.max.locked.memory属性。

   • 运行以下命令:

     cd /etc/hadoop/conf.rollback.datanode
     sudo -u hdfs hdfs --config /etc/hadoop/conf.rollback.datanode datanode -rollback
     

     回滚datanode之后，通过键入Control-C终止控制台会话。

   • 如果启用了HDFS的高可用性，则重新启动HDFS服务。在Cloudera Manager管理控制台，转到HDFS服务并选择Actions > Restart

   • 如果HDFS没有启用高可用性，使用Cloudera Manager管理控制台重新启动所有的namenode和datanode。

     • 转到HDFS服务。
     • 选择Instances选项卡
     • 从列表中选择所有DataNode和NameNode角色。
     • 单击选定的>重启的操作。

5. 如果HDFS没有启用高可用性，则回滚Secondary NameNode

   • (Clusters with TLS enabled only) 在所有secondary NameNode主机(位于临时回滚目录中)上编辑/etc.hadoop/ conf.rollback.secondarynamenode/ssl-server.xml文件，并用实际的明文密码更新密钥存储库密码。

     密码的值如下:

     <property>
         <name>ssl.server.keystore.password</name>
         <value>********</value>
       </property>
       <property>
         <name>ssl.server.keystore.keypassword</name>
         <value>********</value>
       </property>
     

   • (TLS only) 编辑/etc/hadoop/conf.rollback.secondarynamenode/ssl-server.xml文件，并删除hadoop.security.credential.provider.path属性。

   • 登录到secondary NameNode主机并运行以下命令:

     rm -rf /dfs/snn/*
     cd /etc/hadoop/conf.rollback.secondarynamenode/
     sudo -u hdfs hdfs --config /etc/hadoop/conf.rollback.secondarynamenode secondarynamenode -format
     

6. 重新启动HDFS服务。打开Cloudera Manager管理控制台，转到HDFS服务页面，选择Actions > Restart。

   Restart命令页显示重启的进程。在继续之前，等待页面显示成功重启的服务消息。

11.启动密钥管理服务器

重新启动密钥管理服务器。打开Cloudera Manager管理控制台，进入KMS service页面，选择Actions > Start。

12.启动HBase服务

重启HBase服务。打开Cloudera Manager管理控制台，转到HBase服务页面，选择Actions > Start。

如果您在启动HBase时遇到错误，请删除ZooKeeper中的znode，然后再次启动HBase:

1. 在Cloudera管理器中，查找zookeper.znode.parent的值。默认值是/hbase。

2. 在任何HBase网关主机上运行以下命令，连接到ZooKeeper集合:

   zookeeper-client -server zookeeper_ensemble
   

   要找到zookeeper_ensemble使用的值，请打开HBase网关主机上的d的/etc/hbase/conf.cloudera./ HBase -site.xml文件>使用hbase.zookeeper.quorum的值。

   请注意

   如果已经部署了安全集群，则必须使用客户机jaas.conf文件连接到ZooKeeper。您可以在HBase进程目录(/var/run/cloudera-scm-agent/process/)中找到这样的文件。通过在ZooKeeper客户端运行以下命令，使用JVM标志指定jaas.conf:

   CLIENT_JVMFLAGS=
    "-Djava.security.auth.login.config=/var/run/cloudera-scm-		agent/process/HBase_process_directory/jaas.conf"
   
   zookeeper-client -server <zookeeper_ensemble>
   

   将打开ZooKeeper命令行界面。

3. 输入以下命令:

   rmr /hbase
   

13.恢复CDH数据库

从cdh5备份中恢复以下数据库:

• Hive Metastore
• Hue
• Oozie
• Sentry Server

备份和恢复数据库的步骤取决于您为集群选择的数据库供应商和版本，这超出了本文的范围。

重要的

将数据库恢复到您进行备份时的确切状态。不要合并在后续升级过程中可能发生的任何更改。

有关更多信息，请参阅以下供应商资源:

• MariaDB 5.5: http://mariadb.com/kb/en/mariadb/backup-and-restore-overview/
• MySQL 5.5: http://dev.mysql.com/doc/refman/5.5/en/backup-and-recovery.html
• MySQL 5.6: http://dev.mysql.com/doc/refman/5.6/en/backup-and-recovery.html
• PostgreSQL 8.4: https://www.postgresql.org/docs/8.4/static/backup.html
• PostgreSQL 9.2: https://www.postgresql.org/docs/9.2/static/backup.html
• PostgreSQL 9.3: https://www.postgresql.org/docs/9.3/static/backup.html
• Oracle 11gR2: http://docs.oracle.com/cd/E11882_01/backup.112/e10642/toc.htm

14.启动Sentry服务

1. 登录到Cloudera Manager管理控制台。
2. 去Sentry 服务。
3. 单击Actions > Start。

15.回滚Cloudera Search

1. 启动HDFS, Zookeeper和Sentry服务。

2. 通过运行以下命令在Zookeeper中重新初始化配置元数据:

   • export ZKCLI_JVM_FLAGS=“-Djava.security.auth.login.config=~/solr-jaas.conf -DzkACLProvider=org.apache.solr.common.cloud.ConfigAwareSaslZkACLProvider”
     

   • sudo -u solr mkdir /tmp/c5-config-backup
     

   • sudo -u solr chmod 755 /tmp/c5-config-backup
     

   • sudo -u solr hdfs dfs -copyToLocal /user/solr/upgrade_backup/zk_backup/* /tmp/c5-config-backup
     

   • /opt/cloudera/cm/solr-upgrade/solr-rollback.sh zk-meta -c /tmp/c5-config-backup
     

3. 在本地文件系统中重新初始化配置元数据:

   • 在每个配置了SOLR_SERVER角色的主机上，运行以下命令:

     • rm -rf /*
       

     • 的值是通过名为“Solr数据目录”的CM参数配置的(默认为/var/lib/solr)。

   • 检查/localfs_backup目录中的子目录(其中是CM中Solr的“升级备份目录”配置参数中配置的值)。每个子目录:

     • 子目录名指的是在Cloudera Manager中特定主机上的Solr服务器的内部role_id。通过查询Cloudera管理器数据库来识别相应的主机名。要找到role_id:

       • 登录到Cloudera Manager管理控制台。
       • 进入HDFS文件浏览器。
       • 打开solr/upgrade_backup/localfs_backup文件。role_id在这个文件中。

     • 将此子目录的内容复制到CM中的“Solr Data Directory”参数指定的位置。这个参数的默认值是/var/lib/solr

       • 登录到主机H1。

       • 运行以下命令:

         sudo -u solr hdfs dfs -copyToLocal /user/solr/upgrade_backup/localfs_backup/<role_id> /var/lib/solr
         

4. 启动Solr服务。

16.回滚HUE

1. 从备份中恢复app.reg文件:

   • Parcel installations

     rm -rf /opt/cloudera/parcels/CDH/lib/hue/app.reg
     cp -rp app.reg_cm5_cdh5_backup /opt/cloudera/parcels/CDH/lib/hue/app.reg
     

   • Package Installations

     rm -rf /usr/lib/hue/app.reg
     cp -rp app.reg_cm5_cdh5_backup /usr/lib/hue/app.reg
     

17.回滚kafka

运行Kafka的CDH 6集群可以回滚到以前的CDH5/CDK版本，只要inter.broker.protocol.version和log.message.format.version属性未设置为新版本或未从配置中删除。

使用Cloudera管理器执行回滚:

1. 激活前面的CDK包。请注意，当将Kafka从cdh6回滚到cdh5 /CDK时，Kafka集群将重新启动。此场景不支持滚动重启。参见激活包裹。
2. 从Kafka Broker高级配置代码片段(安全阀)配置属性中删除以下属性。
   • Inter.broker.protocol.version
   • log.message.format.version

18.回滚Sqoop 2

升级到cdh6。x要求您在升级之前删除Sqoop 2服务。回滚Sqoop 2服务:

1. 使用Cloudera管理器添加Sqoop 2服务。

2. 从备份中恢复Sqoop 2数据库。有关详细信息，请参阅数据库文档。

   如果您没有为Sqoop 2使用默认的嵌入式Derby数据库，那么恢复为Sqoop 2配置的数据库。否则，从备份中恢复Sqoop 2 metastore目录的repository子目录。这个位置是用Sqoop 2服务器转移目录属性指定的。默认位置是/var/lib/sqoop2对于这个默认位置，Derby数据库文件位于/var/lib/sqoop2/repository中。

19.部署客户端配置

1. 在Home > Status选项卡上，单击集群名称的右侧，并选择部署客户端配置。
2. 单击部署客户端配置。

20.重启集群

1. 在Home > Status选项卡上，单击集群名称的右侧，并选择Restart。

2. 单击下一个屏幕中出现的Restart进行确认。如果您启用了HDFS的高可用性，那么可以选择滚动重启，而不是最小化集群停机时间。命令详细信息窗口显示停止服务的进度。

   当所有服务都成功启动时，任务就完成了，您可以关闭命令详细信息窗口。

21.回滚Cloudera Navigator加密组件

如果您正在回滚任何加密组件(密钥托管服务器、密钥托管KMS、HSM KMS、密钥HSM或导航器加密)，请首先参考:

• Backing up and Restoring Key Trustee Server and Clients
• HSM KMS High Availability Backup and Recovery
• Manually Backing Up Navigator Encrypt

回滚密钥托管服务器

请注意

如果回滚多个加密产品组件，建议从密钥受托人服务器开始。

要回滚密钥受托人服务器，将当前使用的包(例如，版本6.0.0的包)替换为您希望回滚到的版本的包(例如，版本5.14.0)。有关使用包裹的详细说明，请参阅包裹。

回滚秘钥HSM

回滚秘钥HSM:

1. 安装您希望回滚到的Navigator密钥HSM版本

   使用yum安装导航键HSM包:

   sudo yum downgrade keytrustee-keyhsm
   

   默认情况下，Cloudera Navigator密钥HSM安装在/usr/share/keytrustee-server-keyhsm目录中。

2. 重命名之前创建的配置文件

   对于密钥HSM主版本回滚，之前创建的配置文件不使用HSM和密钥托管服务器进行身份验证，因此必须通过重新执行设置和信任命令重新创建这些文件。首先，导航到关键的HSM安装目录并重命名applications.properties, keystore, h和truststore文件:

   cd /usr/share/keytrustee-server-keyhsm/
   mv application.properties application.properties.bak
   mv keystore keystore.bak
   mv truststore truststore.bak
   

3. 初始化秘钥HSM

   与目标HSM分布名称一起运行service keyhsm setup命令:

   sudo service keyhsm setup [keysecure|thales|luna]
   

   更多细节，参考初始化HSM

4. 在关键HSM和关键受托服务器之间建立信任

22.(可选)Cloudera管理器回滚

完成回滚步骤后，您的集群将使用Cloudera Manager 6来管理CDH 5集群。你可以继续使用Cloudera Manager 6来管理你的CDH 5集群，或者你可以通过以下步骤降级到Cloudera Manager 5:

停止Cloudera Manager

1. 停止Cloudera管理服务。

2. 停止Cloudera管理器服务器。

   RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

   sudo systemctl stop cloudera-scm-server
   

   RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

   sudo service cloudera-scm-server stop
   

3. 硬阻止Cloudera经理代理。在所有主机上运行以下命令

   RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

   sudo systemctl stop cloudera-scm-supervisord.service
   

   RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

   sudo service cloudera-scm-agent hard_stop
   

4. 备份存储库目录。您可以使用以下命令创建一个顶级备份目录和一个环境变量来引用该目录。您还可以在以下备份命令中替换另一个目录路径:

   export CM_BACKUP_DIR="`date +%F`-CM"
   mkdir -p $CM_BACKUP_DIR
   

5. 备份现有的存储库目录

   RHEL / CentOS

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

   SLES

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

   Debian / Ubuntu

   sudo -E tar -cf $CM_BACKUP_DIR/repository.tar /etc/apt/sources.list.d
   

恢复Cloudera Manager 5存储库文件

从升级到Cloudera Manager 6.x之前的备份中复制存储库目录。

rm -rf /etc/yum.repos.d/*
cp -rp /etc/yum.repos.d_cm5cdh5/* /etc/yum.repos.d/

恢复包

1. 在所有主机上运行以下命令:

   Operating System	Command
   RHEL	sudo yum remove cloudera-manager-daemons cloudera-manager-agent``sudo yum clean all sudo yum install cloudera-manager-agent
   SLES	sudo zypper remove cloudera-manager-daemons cloudera-manager-agent``sudo zypper refresh -s sudo zypper install cloudera-manager-agent
   Ubuntu or Debian	sudo apt-get purge cloudera-manager-daemons cloudera-manager-agent``sudo apt-get update sudo apt-get install cloudera-manager-agent

2. 在Cloudera Manager服务器主机上运行以下命令

   Operating System	Command
   RHEL	sudo yum remove cloudera-manager-server``sudo yum install cloudera-manager-server
   SLES	sudo zypper remove cloudera-manager-server``sudo zypper install cloudera-manager-server
   Ubuntu or Debian	sudo apt-get purge cloudera-manager-server``sudo apt-get install cloudera-manager-server

恢复Cloudera管理器数据库

从升级到Cloudera Manager 6之前的备份中恢复Cloudera Manager数据库。请参阅数据库供应商提供的过程。

这些数据库包括:

• Cloudera Manager Server
• Reports Manager
• Navigator Audit Server
• Navigator Metadata Server
• Activity Monitor (Only used for MapReduce 1 monitoring).

下面是一个示例命令来恢复MySQL数据库:

mysql -u username -ppassword --host=hostname cm < backup.sql

恢复Cloudera管理器服务器

使用Cloudera Manager 5的备份。x升级到Cloudera Manager之前拍的照片x表示以下步骤:

1. 如果您使用备份命令提供的备份Cloudera管理器，提取您创建的Cloudera管理器5备份档案:

   tar -xf CM5CDH5/cloudera-scm-agent.tar -C CM5CDH5/
   tar -xf CM5CDH5/cloudera-scm-server.tar -C CM5CDH5/
   

2. 在配置运行事件服务器角色的主机上，从Cloudera Manager 5备份恢复事件服务器目录。

   rm -rf /var/lib/cloudera-scm-eventserver/*
   cp -rp /var/lib/cloudera-scm-eventserver_cm5cdh5/* /var/lib/cloudera-scm-eventserver/
   

3. 删除代理运行时状态。在所有主机上运行以下命令

   rm -rf /var/run/cloudera-scm-agent /var/lib/cloudera-scm-agent/response.avro
   

4. 在运行服务监视器的主机上，恢复服务监视器目录

   rm -rf /var/lib/cloudera-service-monitor/*
   cp -rp /var/lib/cloudera-service-monitor_cm5cdh5/* /var/lib/cloudera-service-monitor/
   

5. 在运行主机监视器的主机上，恢复主机监视器目录:

   rm -rf /var/lib/cloudera-host-monitor/*
   cp -rp /var/lib/cloudera-host-monitor_cm5cdh5/* /var/lib/cloudera-host-monitor/
   

6. 从CM5/CDH 5备份中恢复Cloudera Navigator Solr存储目录。

   rm -rf /var/lib/cloudera-scm-navigator/*
   cp -rp /var/lib/cloudera-scm-navigator_cm5cdh5/* /var/lib/cloudera-scm-navigator/
   

7. 在Cloudera Manager服务器上，恢复/etc/ Cloudera -scm- Server /db.properties文件

   rm -rf /etc/cloudera-scm-server/db.properties
   cp -rp cm5cdh5/etc/cloudera-scm-server/db.properties /etc/cloudera-scm-server/db.properties
   

8. 集群中的每个主机上，从备份中恢复/etc/cloudera-scm-agent/config.ini文件。

   rm -rf /etc/cloudera-scm-agent/config.ini
   cp -rp cm5cdh5/etc/cloudera-scm-agent/config.ini /etc/cloudera-scm-agent/config.ini
   

启动Cloudera Manager服务器和代理

• 启动Cloudera管理器服务

  • RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

    sudo systemctl start cloudera-scm-serverIf the Cloudera Manager Server starts without errors, no response displays.

    RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

    sudo service cloudera-scm-server startYou should see the following:Starting cloudera-scm-server: [ OK ]

• 硬重启Cloudera管理器代理

  • RHEL 7, SLES 12, Debian 8, Ubuntu 16.04 and higher

    sudo /etc/init.d/cloudera-scm-agent next_stop_hard
    sudo systemctl stop cloudera-scm-agent
    

  • RHEL 5 or 6, SLES 11, Debian 6 or 7, Ubuntu 12.04 or 14.04

sudo service cloudera-scm-agent hard_restart
```

• 启动Cloudera管理服务。

升级到CDH 6的升级后迁移步骤

如果你已经在你想要升级到CDH6的CDH5.x的集群中部署了Sentry,Hbase,Cloudera Search 或者Spark服务，查看下面的主题已获得额外的升级步骤。

Cloudera数据科学工作台:如果您正在使用clouderan数据科学工作台,请注意,clouderan数据科学工作台并没有自动检测CDH集群的配置更改。对Cloudera数据科学工作台进行完整的重置,这样它就可以通过升级来获取任何更改。对于指令,请参阅Cloudera数据科学工作台文档中的相关已知问题。

Kudu 1.10/CDH 6.3 升级注意事项

重要通知

在升级之前,您应该审查发布notes(CDH 5发布notes或CDH 6发布说明)和您将要安装的Kudu版本的平台需求。

当升级Kudu是，推荐先停止集群中所有的kudu程序，然后再升级所有的软件，最后重启集群中的所有kudu服务。

为了提高安全性，所有人都可读的kerberos的keytab文件将默认不再接受。配置–allow_world_readable_credentials=true 来覆盖这个特性。

Wire Protocol兼容性

Kudu1.10与Kudu之前的版本是兼容的：

• Kudu1.10的客户端可以连接Kudu1.0以及之后的Kudu服务。如果客户端使用了目标服务上没有的特性时，会返回一个错误
• 滚动升级Kudu1.9和1.10服务之间是可行的,不过并未经过严格的验证。我们鼓励用户，停止集群的所有节点，升级软件，重启新版本的守护进程。
• Kudu1.0的客户端可以连接前面提到的没有安全限制的Kudu1.10服务集群

在Kudu1.3版本引入的安全认证特性，在Kudu1.10与1.3之前的版本之间的兼容性中产生了如下的限制：

• 如果Kudu1.10集群配置了需要安全验证，1.3版本之前的客户端无法连接。
• 如果1.10版本安全认证设置的为禁止或者可选，之前版本的客户端依然可以连接

客户端lib库的兼容性

• Kudu 1.10 Java客户端库是API,与Kudu 1.9的ABI-兼容。写在Kudu 1.9上的应用程序将编译并运行到Kudu 1.10客户端库,反之亦然。

• Kudu 1.10 c++客户端是API,与Kudu 1.9兼容。在Kudu 1.9客户库中编写和编译的应用程序将在不修改Kudu 1.10客户端库的情况下运行。在Kudu 1.9客户库中编写和编译的应用程序将在不修改Kudu 1.10客户端库的情况下运行。

• Kudu 1.10 Python客户机与Kudu 1.9兼容。写在Kudu 1.9上的应用程序将继续与Kudu 1.10客户端运行,反之亦然。

定位意识

在升级到CDH 6.2 / Kudu 1.9或更高时,如果分配了机架位置,您应该运行kudu cluster rebalance工具,以确保您现有的表符合机架注意位置策略。

数据表的历史保留时间

默认的Table保留时间被设置为15min到7天来灵活的支持接触较少的备份

集成Hive元数据

Kudu有一个可选的特性，允许将自己的目录和Hive元数据融合(HMS)。在启用现有集群的HMS集成之前,升级Kudu或HMS目录中可能存在的任何表。参见Kudu使用Hive元数据库。

• Re-Indexing Solr Collections After Upgrading to CDH 6
• Apache Spark Post Upgrade Migration Steps

升级JDK

CM、Cloudera Runtime 和CDH需要在集群所有主机上安装一个支持的JDK版本，更多细节，参见下面文档：

• CDP Java Requirements
• Cloudera Enterprise 6 Java Requirements
• Cloudera Enterprise 5 Java Requirements

本文的环境选择为：CentOS7

警告：

如果你从一个更低的major版本的JDK升级到JDK1.8.0或者从JDK1.6到1.7，并且你已经使用AES-256字节加密，你必须安装新的加密文件；(在一个CM部署中，你会自动安装加密文件；对于没有管理的部署，手动安装他们)。在你使用JDK1.8.0-162或更高版本的JDK中，不需要这一步。JDK1.8.0_162版本默认开启了无限制安全认证。

您还必须确保在升级期间保留Java信任存储。

对于Cloudera管理器集群的密钥库和信任库，Cloudera建议如下:

• 为每个主机创建单独的密钥存储库。每个密钥存储库都应该有一个名称，以帮助识别主机-服务器或代理的类型。密钥存储库包含私钥，应该进行密码保护。
• 创建可由整个集群使用的单个信任存储。此信任存储库包含根CA和中间CA，它们用于对TLS/SSL握手期间提供的证书进行身份验证。信任存储不需要密码保护。(有关TLS/SSL和Cloudera的信任库的更多信息，请参见理解密钥库和信任库到信任库

有几个步骤，你可以使用升级JDK:

• 在升级期间安装Java

  如果你升级到Cloudera Manager 6.0.0或更高版本，你可以在Cloudera Manager服务器主机上手动安装JDK 1.8，然后，作为Cloudera Manager升级过程的一部分，你可以指定Cloudera Manager在其余主机上升级JDK。

  请注意

  Cloudera管理器只安装Oracle JDK。您可以使用以下步骤升级到OpenJDK。

• 手动安装Oracle JDK 1.8

  您可以在所有托管主机上手动安装JDK 1.8。如果你升级到任何版本的Cloudera Manager 5.x，你必须使用这个程序。继续下一节中的步骤。

• 手动迁移到OpenJDK

• Using AES-256 Encryption

• Configuring a Custom Java Home Location

• Tuning JVM Garbage Collection

手动安装Oracle JDK 1.8

重要的

手动升级Oracle JDK 1.8需要停机时间来停止和重新启动集群。

您可以在所有托管主机上手动安装Oracle JDK 1.8。如果你升级到任何版本的Cloudera Manager 5.x，您必须使用以下程序:

• 详情见

OpenJDK

必须安装一个受支持的OpenJDK版本。如果您的部署使用的OpenJDK版本低于1.8.0_181，请参阅这个发布说明。

手动安装OpenJDK

手动迁移到OpenJDK

使用aes - 256加密

配置自定义Java主位置

调优JVM垃圾收集

在使用OpenJDK 11时，Cloudera Manager和大多数CDH服务默认使用G1GC作为垃圾收集的方法。(Java 8使用“ConcurrentMarkSweep”(CMS)进行垃圾收集。)在使用G1GC时，垃圾收集的暂停时间更短，因此组件通常响应更快，但它们对过度使用内存更敏感。您应该监视内存使用情况，以确定内存是否过度使用。

请注意

OpenJDK 11只支持Cloudera管理器和CDH 6.3及以上版本。

当集群主机上的内存过度使用时，Cloudera管理器会提醒您。查看这些警报和调整拨款:

1. 登录到Cloudera Manager管理控制台
2. 回到首页>配置>配置问题。
3. 查找标记为内存超量提交验证阈值的条目，并注意受影响主机的主机名。
4. 转到主机>所有主机并单击受影响的主机。
5. 单击Resources选项卡。
6. 向下滚动到内存部分

将显示角色实例及其内存分配的列表。描述列显示可以设置内存分配的配置属性名称。

7. 要调整内存分配，搜索configuration属性并调整该值以减少内存的过度使用。如果主机上运行的角色没有足够的内存，则可能需要将某些角色移动到其他主机上。

8. 在进行任何更改之后，Cloudera Manager会指出服务的配置已经失效，并提示您重新启动服务。

您可能还需要调整用于启动Java进程的Java选项。您可以使用对所有服务角色可用的Cloudera Manager配置属性添加Java启动选项。Cloudera已经为一些需要的服务提供了默认参数。您可以添加这些选项，或者完全覆盖提供的所有Java选项。有关配置G1GC的更多信息。请参阅OpenJDK文档。

如果提供默认选项，则角色配置指定单个值{JAVA_GC_ARGS}。这个值是一个占位符，用于Cloudera Manager和CDH提供的默认Java垃圾收集选项。

要修改Java选项:

1. 登录到Cloudera Manager管理控制台。

2. 转到您想要修改选项的服务。

3. 选择配置选项卡。

4. 在搜索框中输入“Java”。

5. 找到为要修改的角色命名的Java配置选项属性。例如，在HDFS服务中，您将看到DataNode的Java配置选项和JournalNode的Java配置选项等参数。

6. 要添加到Java选项，请在{JAVA_GC_ARGS}占位符之前或之后输入其他选项，用空格分隔。例如:

   {JAVA_GC_ARGS} -XX:MaxPermSize=512M
   

7. 要替换默认的Java选项，请删除{JAVA_GC_ARGS}占位符，并用一个或多个Java选项替换它，用空格分隔。

8. 服务现在将拥有一个过时的配置，必须重新启动。参见重新启动服务

   ​ 表1 默认的Java选项

Service and Role	Default Java 8 Options	Default Java 11 Options
HDFS DataNodeHDFS NameNodeHDFS Secondary NameNode	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled	-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled
Hive Metastore ServerHiveServer 2WebHCat Server	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled	None, G1GC is enabled by default.
HBase REST ServerHBase Thrift ServerHBase MasterHBase RegionServer	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled	None, G1GC is enabled by default.
HBase Region Server	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps	-verbose:gc -Xlog:gc
MapReduce JobTrackerMapReduce TaskTracker	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled	None, G1GC is enabled by default.
Solr Server	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled	None, G1GC is enabled by default.
YARN JobHistory ServerYARN NodeManagerYARN Resource Manager	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -Dlibrary.leveldbjni.path={{CMF_CONF_DIR}}	-Dlibrary.leveldbjni.path={{CMF_CONF_DIR}}

升级操作系统

本主题描述将Cloudera Manager管理的主机的操作系统升级到更高版本(包括主版本和小版本)所需的额外步骤。

将操作系统升级到一个更高的版本，但在同一主要版本中，这种升级称为次要版本升级。例如，从Redhat 6.8升级到6.9。这是一个相对简单的过程，包括正确地关闭所有组件、执行操作系统升级，然后以相反的顺序重新启动所有组件。

将操作系统升级到不同的主版本称为主版本升级。例如，从Redhat 6.8升级到7.4。这是一个更为复杂的过程，而一些操作系统不支持这些升级。因此，本主题不讨论升级特定操作系统的过程。

本主题主要描述所有其他步骤，比如备份必要的文件、删除和重新安装所有必要的Cloudera企业包和包裹。

开始操作系统升级

前期准备

• 确保Cloudera管理器和CDH或Cloudera运行时的版本支持您的新操作系统。

  • 使用Cloudera Manager 5.x时，请参阅操作系统要求。
  • 使用Cloudera Manager 6.x时，请参阅操作系统要求。
  • 请参阅CDP数据中心的操作系统要求。

  如果您使用的是不支持的版本，请参阅升级Cloudera Manager或升级集群。

• 通过访问https://archive.cloudera.com或本地包存储库，确保主机能够访问新操作系统支持的Cloudera Manager服务器、守护程序包和代理包。

• 如果你安装了一个补丁包，确保你有相同的包或包用于新的操作系统，并已提供给Cloudera管理器。

• 要知道，为操作系统执行一个重大的版本升级可能是非常棘手和危险的。

在升级操作系统之前备份主机文件

本主题描述在升级操作系统之前如何备份主机上的重要文件。

备份

1. 创建一个备份目录.

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

2. 备份agent目录和运行状态

   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
   

3. 备份CM服务的目录:

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

请注意

建议进行备份，但对于较小的版本升级并不总是必需的。

在升级操作系统之前

本主题描述在Cloudera管理器管理的主机上升级操作系统之前必须执行的步骤。

1.decommission 并停止运行角色

1. 登录到Cloudera Manager管理控制台。

2. 从“所有主机”页，选择要升级的主机。Cloudera建议每次只升级一台主机。

3. 从“操作”菜单中选择Begin Maintenance (Suppress Alerts/Decommission) 。

4. 如果每个节点的操作系统升级过程花费的时间少于30分钟，则不需要使DataNode decommission 。

   如果Cloudera Manager和CDH版本都是5.14或更高版本，你还可以选择Take DataNode Offline功能。

   如果有疑问，decommission 角色。

   • 当一个DataNode退役时，NameNode确保DataNode的每个块仍然在整个集群中可用，这是由复制因子指定的。这个过程包括小批量地复制DataNode上的块。在DataNode有几千个块的情况下，退役需要几个小时。

   • 当一个DataNode被关闭而没有退役时:

     • NameNode将DataNode标记为死，默认值为10m 30s(由dfs.heartbeat.interval和dfs.heartbeat.recheck.interval配置属性控制)。
     • NameNode计划将丢失的副本放在其他DataNodes上。
     • 当DataNode恢复在线并向NameNode报告时，NameNode会安排将块复制到它，而其他节点已经decommission ，或者新文件被写入HDFS。

   • 你也可以通过增加这些属性的值来加速DataNode的decommissioning :

     • dfs.max- reply -streams:用于复制数据的同时流的数量。

     • dfs.balance.bandwidthPerSec:每个DataNode可以用于平衡的最大带宽量，单位是字节/秒。

     • dfs.namenode.replication.work.multiplier.per.iteration:需要重新启动的NameNode配置，默认为2，但可以提高到10或更高。

       当NameNode通过DataNode心跳发送这样的命令列表时，这决定了在DataNode上并行开始复制的块传输总量。实际数量是通过将该值乘以集群中活动节点的总数来获得的。结果号是每个DataNode心跳要立即传输的块数。

警告

如果没有启用HDFS、HBase、MapReduce、YARN、Oozie或Sentry的高可用性，停止运行单主角色将导致该服务中断。具体来说，其他主机上的从属角色会突然停止。Cloudera建议在主机升级之前停止这些服务。

重要的

当升级属于ZooKeeper quorum一部分的主机时，请确保大多数quorum仍然可用。

2.停止Cloudera管理服务器和代理

1. 硬停止Cloudera经理代理

   sudo systemctl stop cloudera-scm-supervisord.service
   

   重要的

   这将要求您使用hard_stop_confirmed进行确认，因为这将无条件终止主机上的所有Hadoop服务(如果有的话)。

2. 停止Cloudera管理服务。

3. 停止Cloudera管理器服务器。

   sudo systemctl stop cloudera-scm-server
   

3.停止数据库

如果在此主机上运行其他数据库服务器，也必须停止它们。

4.升级操作系统

重要的

当此主机上没有运行Hadoop服务或Cloudera Manager角色时，您可以继续升级此主机的操作系统，请确保保持数据分区(例如，dfs.data.dir)不变。

使用你的操作系统供应商提供的操作系统升级程序(例如:RedHat或Ubuntu)下载他们的软件并执行操作系统升级。

升级操作系统后

最小所需角色:集群管理员(也由完整管理员提供)在使用Cloudera管理器管理数据中心集群时，他的特性是不可用的。

本主题描述如何在Cloudera Manager管理的主机上升级操作系统。

1.启动数据库

如果数据库服务器已停止，则必须重新启动它们。

2.启动Cloudera管理服务器和代理

适当的服务通常会在重新启动时自动启动。否则，根据需要启动Cloudera管理服务器和代理。

1.如果rpcbind服务没有自动启动，则启动它。

sudo service rpcbind start

2.启动Cloudera管理器代理。

sudo systemctl start cloudera-scm-agent

3.启动Cloudera管理器服务器。

sudo systemctl start cloudera-scm-server

3启动角色

1. 从All Hosts页面，选择刚刚升级的主机。
2. 从“操作”菜单中选择**End Maintenance (Enable Alerts/Decommission)**并确认。
3. 启动在此主机上运行并已停止的任何Cloudera管理服务角色。
   作系统要求](https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_os_requirements.html)。

• 请参阅CDP数据中心的操作系统要求。

如果您使用的是不支持的版本，请参阅升级Cloudera Manager或升级集群。

• 通过访问https://archive.cloudera.com或本地包存储库，确保主机能够访问新操作系统支持的Cloudera Manager服务器、守护程序包和代理包。

• 如果你安装了一个补丁包，确保你有相同的包或包用于新的操作系统，并已提供给Cloudera管理器。

• 要知道，为操作系统执行一个重大的版本升级可能是非常棘手和危险的。

在升级操作系统之前备份主机文件

本主题描述在升级操作系统之前如何备份主机上的重要文件。

备份

1. 创建一个备份目录.

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

2. 备份agent目录和运行状态

   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
   

3. 备份CM服务的目录:

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

请注意

建议进行备份，但对于较小的版本升级并不总是必需的。

在升级操作系统之前

本主题描述在Cloudera管理器管理的主机上升级操作系统之前必须执行的步骤。

1.decommission 并停止运行角色

1. 登录到Cloudera Manager管理控制台。

2. 从“所有主机”页，选择要升级的主机。Cloudera建议每次只升级一台主机。

3. 从“操作”菜单中选择Begin Maintenance (Suppress Alerts/Decommission) 。

4. 如果每个节点的操作系统升级过程花费的时间少于30分钟，则不需要使DataNode decommission 。

   如果Cloudera Manager和CDH版本都是5.14或更高版本，你还可以选择Take DataNode Offline功能。

   如果有疑问，decommission 角色。

   • 当一个DataNode退役时，NameNode确保DataNode的每个块仍然在整个集群中可用，这是由复制因子指定的。这个过程包括小批量地复制DataNode上的块。在DataNode有几千个块的情况下，退役需要几个小时。

   • 当一个DataNode被关闭而没有退役时:

     • NameNode将DataNode标记为死，默认值为10m 30s(由dfs.heartbeat.interval和dfs.heartbeat.recheck.interval配置属性控制)。
     • NameNode计划将丢失的副本放在其他DataNodes上。
     • 当DataNode恢复在线并向NameNode报告时，NameNode会安排将块复制到它，而其他节点已经decommission ，或者新文件被写入HDFS。

   • 你也可以通过增加这些属性的值来加速DataNode的decommissioning :

     • dfs.max- reply -streams:用于复制数据的同时流的数量。

     • dfs.balance.bandwidthPerSec:每个DataNode可以用于平衡的最大带宽量，单位是字节/秒。

     • dfs.namenode.replication.work.multiplier.per.iteration:需要重新启动的NameNode配置，默认为2，但可以提高到10或更高。

       当NameNode通过DataNode心跳发送这样的命令列表时，这决定了在DataNode上并行开始复制的块传输总量。实际数量是通过将该值乘以集群中活动节点的总数来获得的。结果号是每个DataNode心跳要立即传输的块数。

警告

如果没有启用HDFS、HBase、MapReduce、YARN、Oozie或Sentry的高可用性，停止运行单主角色将导致该服务中断。具体来说，其他主机上的从属角色会突然停止。Cloudera建议在主机升级之前停止这些服务。

重要的

当升级属于ZooKeeper quorum一部分的主机时，请确保大多数quorum仍然可用。

2.停止Cloudera管理服务器和代理

1. 硬停止Cloudera经理代理

   sudo systemctl stop cloudera-scm-supervisord.service
   

   重要的

   这将要求您使用hard_stop_confirmed进行确认，因为这将无条件终止主机上的所有Hadoop服务(如果有的话)。

2. 停止Cloudera管理服务。

3. 停止Cloudera管理器服务器。

   sudo systemctl stop cloudera-scm-server
   

3.停止数据库

如果在此主机上运行其他数据库服务器，也必须停止它们。

4.升级操作系统

重要的

当此主机上没有运行Hadoop服务或Cloudera Manager角色时，您可以继续升级此主机的操作系统，请确保保持数据分区(例如，dfs.data.dir)不变。

使用你的操作系统供应商提供的操作系统升级程序(例如:RedHat或Ubuntu)下载他们的软件并执行操作系统升级。

升级操作系统后

最小所需角色:集群管理员(也由完整管理员提供)在使用Cloudera管理器管理数据中心集群时，他的特性是不可用的。

本主题描述如何在Cloudera Manager管理的主机上升级操作系统。

1.启动数据库

如果数据库服务器已停止，则必须重新启动它们。

2.启动Cloudera管理服务器和代理

适当的服务通常会在重新启动时自动启动。否则，根据需要启动Cloudera管理服务器和代理。

1.如果rpcbind服务没有自动启动，则启动它。

sudo service rpcbind start

2.启动Cloudera管理器代理。

sudo systemctl start cloudera-scm-agent

3.启动Cloudera管理器服务器。

sudo systemctl start cloudera-scm-server

3启动角色

1. 从All Hosts页面，选择刚刚升级的主机。
2. 从“操作”菜单中选择**End Maintenance (Enable Alerts/Decommission)**并确认。
3. 启动在此主机上运行并已停止的任何Cloudera管理服务角色。
4. 启动任何由于缺乏高可用性而停止的服务。