Notes and warnings to consider before upgrading to CDP.
Loading Filters ...
7.0.3 7.1.1 7.1.2 7.1.3 7.1.4
7.2.4 7.3.1 7.4.4 7.5.1 7.6.1 7.6.7 7.7.1
7.7.3
7.11.3
7.1.7.2000 7.1.8 7.1.7.1000 7.1.7 7.1.6 7.1.5
7.1.4 7.1.3 7.1.2 7.1.1
7.1.9
Minimum Required Role: Cluster
Administrator Full
Administrator ) This feature is not available when using Cloudera
Manager to manage Data Hub clusters.
Note the following before upgrading your clusters:
warning
If there is any failure during the upgrade process, you must contact
Cloudera customer support.
note
Cloudera recommends all upgrades to happen in a maintenance window
by throttling and scaling down workloads during that time as a best practice.
important
The embedded
PostgreSQL database is NOT supported in production
environments.
The following services are no longer supported as of Enterprise
6.0.0:
Sqoop 2
MapReduce 1
Spark 1.6
Record Service
Running Apache Accumulo on top of CDP Private Cloud Base 7.1.x
cluster is not currently supported. If you try to upgrade to CDP Private Cloud Base 7.1.x, you will be asked to remove the Accumulo
service from your cluster.
Upgrading Apache HBase from CDH to Cloudera Runtime 7.1.1 gives you a warning in
Cloudera Manager that the Dynamic Jars Directory feature property
hbase.dynamic.jars.dir is deprecated. You can ignore this warning when
using Apache HBase with HDFS storage on CDP Private Cloud Base . The
hbase.dynamic.jars.dir property is incompatible with Apache HBase on
cloud deployments using cloud storage.
The minor version of Cloudera Manager you
use to perform the upgrade must be equal to or greater than the
CDH or Cloudera Runtime minor version. Cloudera recommends that
you upgrade to the latest maintenance version of Cloudera Manager
before upgrading your cluster. See Supported Upgrade
Paths . To upgrade Cloudera Manager, see Upgrading Cloudera Manager 7 .
For example:
Supported:
Cloudera Manager 7.1 or higher 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
note
After upgrading from CDH to CDP, the NodeManager recovery feature is
enabled by default. This means that the
yarn.nodemanager.recovery.enabled property is set to
true. Cloudera recommends that you keep the
NodeManager recovery feature enabled. If you set this property to
false in your CDP cluster and then upgrade to a later
CDP version, the feature will remain disabled.
Cruise Control might fail during an upgrade
Cruise Control does not function properly during the upgrade
warning
Cruise Control does not work properly during the upgrade process of the
Kafka service. This also applies to rolling upgrades.
Data replication with Streams Replication Manager might stop during a rolling
upgrade
important
In Cloudera Runtime 7.1.8, Streams Replication
Manager (SRM) configuration properties and environment variables changed in a
non-backward-compatible manner. As a result, during a rolling upgrade, SRM Driver roles may
not be able to continue replicating data and parts of the replication work might stop until
all SRM Drivers are restarted during the upgrade. The downtime differs depending on the
number of SRM Drivers and the time it takes for rolling restarts to finish.
Prometheus instances used by Streams Messaging Manager require reconfiguration
following an upgrade
important
In Cloudera Runtime 7.1.9, a number of backward-incompatible changes are introduced for
Kafka Connect. As a result, Prometheus instances set up as the metrics store for Streams
Messaging Manager (SMM) will be unable to scrape Kafka Connect metrics.
Following an upgrade you must reconfigure your Prometheus instance, otherwise, you will
not be able to continue monitoring Kafka Connect with SMM. Reconfiguration steps are
provided in Step 9: Complete Post-Upgrade steps for upgrades to CDP
Private Cloud Base .
The integration between Streams Messaging Manager and Streams Replication Manager is
changed
important
In Cloudera Runtime 7.1.6 and higher, the way Streams Messaging Manager (SMM) integrates
with Streams Replication Manager (SRM) has changed. SMM can only connect to and monitor an
SRM service that is running in the same cluster as SMM. Monitoring an SRM service that is
running in a cluster that is external to SMM is no longer supported.
Connectivity between the two services is disabled by default after a successful upgrade.
If you want to continue using SMM to monitor SRM, you must reconnect the two services
following the upgrade.
important
In Cloudera Runtime 7.1.8 and higher data at rest
encryption for Kudu and range-specific hash schemas are supported features. However, if
these features are used, a rollback is no longer possibble. That is because a rollback would
require to disable the encryption and delete all partitions with custom hash schemas.
important
Spark 2 will be deprecated in Cloudera Runtime
7.1.9. Therefore, 7.1.9 is the last runtime release where Spark 2 is supported. For more
information, see Deprecation Notices in Cloudera Runtime.
important
When you upgrade from the lower version of CDP Private Cloud Base to CDP Private Cloud
Base 7.1.9, the quota related information will be repaired during the cluster upgrade.
The upgrade activity will take time based on number of keys present in the system. This
is a one time activity to correct the quota and usages information for space and
namespace usages.
If you have the Ozone HttpFS role added to the Ozone service on your 7.1.8 cluster,
you must stop and delete the Ozone HttpFS role from the Ozone service before upgrading
the Cloudera Runtime cluster to 7.1.9. After you upgrade the Cloudera Runtime cluster to
7.1.9, you can add the HttpFS role back to the Ozone service.
Using Cloudera Manager 7.7.1, if you are upgrading from CDP Private Cloud Base 7.1.8
with Ozone parcel 1.0 to CDP Private Cloud Base 7.1.9 using Cloudera Manager 7.11.3,
then you must
Deactivate and undistribute the Ozone parcel 1.0 on the CDP Private Cloud Base
7.1.8 cluster
Upgrade Cloudera Manager from 7.7.1 to 7.11.3. Do not restart the CDP
cluster.
Upgrade from CDP Private Cloud Base 7.1.8 to CDP Private Cloud Base 7.1.9.
HDFS
warning
Cloudera recommends you to not create any new encryption zone unless HDFS metadata
is finalized.
Ozone notes
important
Using Cloudera Manager 7.7.1, if you are upgrading from CDP Private Cloud Base 7.1.8
with Ozone parcels to CDP Private Cloud Base 7.1.9 using Cloudera Manager 7.11.3, then
you must
If you have Ozone parcel 1.0 on the CDP Private Cloud Base 7.1.8 cluster, you
must deactivate and undistribute Ozone parcel 1.0. If you have Ozone parcel 2.x on
the CDP Private Cloud Base 7.1.8 cluster, you must only deactivate Ozone parcel
2.x.
Upgrade Cloudera Manager from 7.7.1 to 7.11.3. Do not restart the CDP
cluster.
Upgrade from CDP Private Cloud Base 7.1.8 to CDP Private Cloud Base 7.1.9.
When you upgrade from the lower version of CDP Private Cloud Base to CDP Private Cloud
Base 7.1.9, the quota related information will be repaired during the cluster upgrade.
The upgrade activity will take time based on number of keys present in the system. This
is a one time activity to correct the quota and usages information for space and
namespace usages.
If you have the Ozone HttpFS role added to the Ozone service on your 7.1.8 cluster,
you must stop and delete the Ozone HttpFS role from the Ozone service before upgrading
the Cloudera Runtime cluster to 7.1.9. After you upgrade the Cloudera Runtime cluster to
7.1.9, you can add the HttpFS role back to the Ozone service.
Known issue during 7.1.7 SP2 to 7.1.9 upgrade
OPSAPS-68279: When upgrading CDp 7.1.7 SP2 to CDP 719, sometimes
the command step DeployClientConfig fails due to the following
error:
Error Message: Client configuration generation requires the following additional parcels to be activated:[cdh]This can be because of the failure of the activation of the
7.1.9 parcels. To verify:
Navigate to the parcels page.
See if the following error is displayed: Error when distributing to
<hostname>: Sc
file/opt/cloudera/parcels/.flood/CDH-7.1.9-1.cdh7.1.9.p0.43968053-el7.parcel/CDH-7.1.
1.cdh7.1.9.0.43968053-el7.parcel does not exist.
Using the error above, identify the host and ssh into the host by running the
command ssh <hostname> .
Navigate to the agent directory by running the command cd
/var/log/cloudera-scm-agent .
Find the following pattern in agent log file(s) Exception: Untar failed
with return code: 2, with tar output: stdout: [b''], stderr: [b'\ngzip: stdin:
invalid compressed data--format violated\ntar: Unexpected EOF in archive\ntar:
Unexpected EOF in archive\ntar: Error is not recoverable: exiting
now\n'].
If the above exception appears, you must restart the agent on that host by running the command systemctl restart cloudera-scm-agent .
After the agent restarts, click resume to continue with the upgrade.
