Cloudera Docs

Cloudera JDK upgrade path options

Before the upgrade can commence, the administrator must first understand the starting point and the target environment of Cloudera release, so the matching JDK release could be used accordingly.

Option 1: Upgrading from a JDK 17 certified Cloudera release

This option refers to a state where the current platform runs over a certified JDK 17, i.e., Cloudera Runtime 7.1.9.x / Cloudera Runtime 7.3.1.x and with Cloudera Manager 7.11.3 (CHF7) or higher, which also supports ZDR (Zero Downtime Restart).

Step-by-Step upgrade process for the above scenario
  1. Install OpenJDK 17 on all hosts (for example, dnf install java-17-openjdk-devel).
  2. Use the command alternatives --config java to validate that the configured JDK is indeed JDK 17. If the current setting is incorrect, then set it to JDK 17.
  3. Restart the Cloudera Manager Server(s).
  4. Log in to the Cloudera Manager UI and restart the Cloudera Management Services.
  5. Restart the cluster (rolling restart if ZDR is required) to make the cluster run on JDK17.

Once you run the entire cluster on JDK 17, remove the older JDK releases from all hosts (for example, use dnf remove java-11-openjdk-headless, which will remove all JDK 11 rpms).

You can now continue with the upgrade to a higher release such as Cloudera Runtime 7.3.2 / Cloudera Manager 7.13.2 or higher.

Option 2: Upgrading from a non-certified JDK 17 Cloudera release

This option referes to a state where the current platform release is not certified with JDK 17 such as Cloudera Runtime 7.1.7.SP3, and you are not performing a direct upgrade to Cloudera Runtime 7.3.2 / Cloudera Manager 7.13.2. Therefore, you must first bring the service to a JDK 17 compatible version, such as Cloudera Runtime 7.1.9.x or higher and Cloudera Manager 7.11.3 (CHF7) or higher.

Step-by-Step upgrade process for the above scenario
  1. If your current service runs on either JDK 8 or JDK 11, log in to the Cloudera Manager UI and go to the left menu: Hosts > All Hosts.
  2. Click on the Configuration tab.
  3. Select Category > Advanced.
  4. Set the Java Home Directory property to the current JDK location the cluster uses (for example, /usr/lib/jvm/java-11-openjdk or /usr/lib/jvm/java-1.8.0-openjdk).
  5. Click Save Changes.
  6. Now you can install OpenJDK 17 on all hosts (for example, dnf install java-17-openjdk-devel).
  7. Use the command alternatives --config java to validate that the configured JDK is indeed JDK 17. If the current setting is incorrect, then set it to JDK 17.
  8. Stop the current old Cloudera Manager. In case more than one Cloudera Manager exists (for example, in an HA setup), stop both Cloudera Manager instances.

  9. Upgrade the old Cloudera Manager Server(s) to a JDK 17 supported Cloudera Manager release (for example, Cloudera Manager 7.13.1.x).

  10. Start only one of the new Cloudera Manager Servers (in case of more than one Cloudera Manager).
  11. Upgrade the Cloudera Manager Agents from the Cloudera Manager UI.
  12. As JDK 17 is already present on the hosts, restart the Cloudera Management Service (through the Cloudera Manager UI); it will start successfully.
  13. Perform the following steps to remove the customized JDK location which is set in Step 4. so the system will use the default JDK 17 instead:
    1. Go to the host configurations screen in the Cloudera Manager UI (where you set the JDK location previously on Step 4).
    2. Reset the JDK location setting to the default (i.e., remove the specific JDK path you set on the host configurations).

      This action ensures that the Runtime services will automatically pick up the newly installed system-wide JDK 17 during their next restart.

  14. Restart the Cloudera Management Services to ensure they fully recognize and apply the host configuration change (the removal of the explicit JDK path).
  15. Start the Runtime upgrade wizard to upgrade the cluster to a JDK 17 certified Runtime release (for example, Cloudera Runtime 7.3.x).
  16. Once you completed the upgrade and the entire cluster now runs on JDK 17, remove the older JDK releases from all hosts. For example, use dnf remove java-11-openjdk-headless or dnf remove java-1.8.0-openjdk-headless, which will remove all JDK 11 or JDK 8 RPMs and their dependencies.