Upgrading Db2 Warehouse deployments with an HADR configuration

When you upgrade Cloud Pak for Data you must also upgrade any Db2 Warehouse deployments with high availability disaster recovery (HADR) configurations on the platform. Steps vary depending on the Cloud Pak for Data version you are upgrading to.

Before you begin

  • Upgrade Cloud Pak for Data and Db2 Warehouse to the intended version. Replace the steps to upgrade your deployed Db2 Warehouse instances with the following procedure.
  • If you have created an external etcd store with etcd that is packaged with Db2 Warehouse, see Upgrading the external etcd store created with the Db2 etcd image for instructions on how to upgrade to the latest image. These steps should be performed after the HADR rolling upgrade is complete.
Restriction: Only SMP deployments on Db2 Warehouse can be configured to use HADR.
Attention: Since the release of Db2 Warehouse 11.5.7.0-cn5, the Db2uCluster CR requires NetworkPolicies that permit HADR communication between deployments. If you are upgrading from Db2 Warehouse 11.5.7.0-cn4 or earlier, you need to manually create these NetworkPolicies before upgrading your Db2uCluster instances. See Creating Db2 Warehouse NetworkPolicy resources on OpenShift HADR deployment upgrade.

About this task

The amount of interruption to access your HADR deployment will vary depending on the version of Cloud Pak for Data you upgrade to:
  • If you are upgrading to Cloud Pak for Data 4.6.x, only a momentary interruption occurs when processing is switched from one database to the other. Depending on how automatic client reroute (ACR) is configured, the interruption would be the time it takes for ACR to switch between the primary and standby connection.

Procedure

To upgrade a Db2 Warehouse HADR deployment, complete the following steps.

This procedure will configure Db2 Warehouse on Cloud Pak for Data to keep at least one HADR database available throughout the upgrade process. A momentary interruption occurs when processing is switched from one database to the other.

Important: The primary and principal standby databases must be in PEER state before you start the upgrade.

  1. Modify environment and version variables for your deployments: 
    DB2UCLUSTER_PRIMARY="db2wh-crd-hadr-primary"
DB2UCLUSTER_STANDBY="db2wh-crd-hadr-standby"
PROJECT_PRIMARY="zen"
PROJECT_STANDBY="zen"
DB2_VERSION="11.5.7.0-cn7"
  2. Run the stop governor command on your deployments.
    Note: Governor does not run on auxiliary standbys. This step isn't necessary on auxiliary deployments.
    Run the following commands on your principal standby deployment first, then your primary deployment.
    oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- sv stop governor
    oc exec -it c-${DB2UCLUSTER_PRIMARY}-db2u-0 -n ${PROJECT_PRIMARY} -- sv stop governor
  3. Upgrade your standby deployment.

    Patch the Db2uCluster custom resource to the new version by running the following command:

    oc patch db2ucluster ${DB2UCLUSTER_STANDBY} -n ${PROJECT_STANDBY} --type merge -p "{\"spec\":{\"version\":\"${DB2_VERSION}\"}}"
    The Db2uCluster will return READY when the standby deployment upgrade is complete. Run the following command to return the status:
    oc get db2ucluster ${DB2UCLUSTER_STANDBY} -n ${PROJECT_STANDBY}
    If there are auxiliary deployments in the HADR topology, upgrade them one at a time. Repeat this step and wait for each deployment to return READY status.
  4. Perform a role switch to the standby database to set it as the new primary database.

    Run the following commands:

    oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- su - db2inst1
    db2 takeover hadr on db ${DBNAME}
  5. Upgrade the new standby (former primary) deployment.

    Patch the Db2uCluster custom resource to the new version by running the following command:

    oc patch db2ucluster ${DB2UCLUSTER_PRIMARY} -n ${PROJECT_PRIMARY} --type merge -p "{\"spec\":{\"version\":\"${DB2_VERSION}\"}}"
    The Db2uCluster will return READY when the standby deployment upgrade is complete. Run the following command to return the status:
    oc get db2ucluster ${DB2UCLUSTER_PRIMARY} -n ${PROJECT_PRIMARY}
  6. Update the databases.

    Run the db2u_update.sh update script on the current primary (former standby) deployment with the -db parameter:

    oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- bash
    su - db2inst1 -s /bin/bash -c '/db2u/scripts/db2u_update.sh -db'
  7. Wait for the log replay to complete.

    Ensure the HADR pair has reached PEER state again by running the following command and reviewing the status:

    oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- manage_hadr -status
  8. Deactivate, then activate the database in the current standby (former primary) deployment by running the following commands: 
    oc exec -it c-${DB2UCLUSTER_PRIMARY}-db2u-0 -n ${PROJECT_PRIMARY} -- su - db2inst1
    db2 deactivate db ${DBNAME}
    db2 activate db ${DBNAME}
    If there are auxiliary deployments in the HADR topology, repeat this step to deactivate and activate each deployment.
  9. Perform a role switch to revert back to the original primary deployment by running the following commands: 
    oc exec -it c-${DB2UCLUSTER_PRIMARY}-db2u-0 -n ${PROJECT_PRIMARY} -- su - db2inst1
    db2 takeover hadr on db ${DBNAME}
  10. Deactivate, then activate the database in the standby deployment by running the following commands: 
    oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- su - db2inst1
    db2 deactivate db ${DBNAME}
    db2 activate db ${DBNAME}
  11. Start Governor on the primary deployment by running the following commands: 
    oc exec -it c-${DB2UCLUSTER_PRIMARY}-db2u-0 -n ${PROJECT_PRIMARY} -- su - db2inst1
    ${HOME}/governor/governor.sh start
  12. Start Governor on the standby deployment by running the following commands: 
    oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- su - db2inst1
    ${HOME}/governor/governor.sh start