Upgrading version 2.1.0 to 2.1.3 of Workload XM

Steps for upgrading version 2.1.0 to 2.1.3 of Workload XM.

Describes how to upgrade from version 2.1.0 to 2.1.3.
These steps assume that you have:
  • Scheduled the upgrade and informed your users of the Workload XM service interruption.
  • Verified that your Workload XM cluster is running a supported version of Cloudera Manager and the Cloudera Data Platform (CDP) and that your Workload clusters are running a supported version of Cloudera Manager and Cloudera Platform.
  • Recorded the Cloudera Manager host name of the server that contains an installation of Workload Manager, as this value is required during upgrading.
  • Downloaded the 2.1.3 version of the Workload XM installation parcel and checksum from the Cloudera Downloads website.
  • Downloaded the 2.1.3 version of the Workload XM installation CSD (.jar) file from the Cloudera Downloads website.
  • Verified that there are no remaining messages in the ZooKeeper queue, by doing the following:
    1. In a terminal log in to a host running ZooperKeeper and list the current queues by running the following command:
      /opt/cloudera/parcels/CDH/lib/zookeeper/bin/zkCli.sh -server [zk_server]:2181 ls /wxm/onprem/zkqueue
      The following terminal output is an example of a current queue output:
      HiveAudit, HiveHistoryProtobuf, HiveOnMrTable, ImpalaQueryProfile, LlapHistoryProtobuf, MrJhist, MrTaskLog, OozieWorkflow, Pse, SdxDetails, SparkEventLog, SparkTaskLog, TezHistoryProtobuf, YarnApp, YarnAppMetrics, sigmaadb-broadcast, upload-processing-update-queue
    2. Verify that all the queues are empty by running the following:
      for q_n in HiveAudit HiveHistoryProtobuf HiveOnMrTable ImpalaQueryProfile LlapHistoryProtobuf MrJhist MrTaskLog OozieWorkflow Pse SdxDetails SparkEventLog SparkTaskLog TezHistoryProtobuf YarnApp YarnAppMetrics sigmaadb-broadcast upload-processing-update-queue
        do
          echo $q_n: $(/opt/cloudera/parcels/CDH/lib/zookeeper/bin/zkCli.sh -server [zk_server]:2181 stat -w /wxm/onprem/zkqueue/${q_n} | grep "numChildren")
        done
    3. Verify that all the count values are 0.
    4. If there are messages in the queue, do the following:
      1. Stop the DBUS services, which stops any new incoming data.
      2. Allow Workload XM to finish processing any existing messages.
      3. Stop any remaining components.
  • Stopped the Workload XM service and its services.
  1. Verify that the Workload XM Service and its services are stopped.
  2. Do the following:
    1. In a terminal, SSH into the Cloudera Manager host server.
    2. Copy the downloaded parcel (.parcel) and its checksum (.sha) file to the /opt/cloudera/parcel-repo directory of the Cloudera Manager Server on the Workload XM on-premises cluster.
    3. Copy the downloaded CSD (.jar) file to the opt/cloudera/csd directory of the Cloudera Manager Server on the Workload XM on-premises cluster.
  3. In the /opt/cloudera/parcel-repo directory, set the ownership of the parcel and sha files to cloudera-scm:cloudera-scm.
  4. In the /opt/cloudera/csd directory, set the ownership of the CSD .jar file to cloudera-scm:cloudera-scm.
  5. In a supported web browser on the Workload XM on-premises cluster, log in to Cloudera Manager.
  6. In Cloudera Manager, select Clusters, Parcels, and then Distribute.
    In the list of parcels, the latest version appears with a gray Distribute label.
  7. Activate the Workload XM installation files by selecting Activate Only. Do not restart.
  8. From the Cloudera Manager Host, restart the Cloudera Manager Server by entering the following:
    service cloudera-scm-server restart
  9. Navigate to the Workload XM service in the Cloudera Manager UI and then from the Actions menu do the following:
    1. Run the command to create the Cloudera Sigma PSE extended directory by selecting Create the cloudera-sigma-pse-extended Directory.
    2. Run the command to upgrade the database schemas by selecting Upgrade Database Schemas.
    3. Restart the Workload XM service, by selecting Restart.
    As shown in the following image:


  10. Once all the roles have started, from the Actions menu, select Repair Workload Database.