Applying rolling updates to your Db2 HADR databases

To complete a rolling update on your Db2 HADR database instance, edit the source YAML of the custom resource (CR) that is associated with your Db2 service.

Before you begin

Note: This procedure also applies to Db2uInstance CR. To modify this procedure for use with Db2uInstance CR, use db2uinstance in place of db2ucluster.
  • Upgrade the Db2 service. For more information, see Upgrading Db2.
  • Ensure your primary and principal standby databases are in PEER state.
  • If you have created an external etcd store with etcd that is packaged with Db2, 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, or between steps 17 and 18 in the task procedure.

About this task

If you are upgrading to Db2, there is an interruption when processing is switched from one database to the other. The duration of the interruption depends on the time it takes for automatic client reroute (ACR) to switch between the primary and standby connection.
Note: This upgrade procedure keeps at least one HADR database available throughout the upgrade process.

Procedure

  1. Modify environment and version variables for your deployments:
    DB2UCLUSTER_PRIMARY="db2oltp-crd-hadr-primary"
    DB2UCLUSTER_STANDBY="db2oltp-crd-hadr-standby"
    PROJECT_PRIMARY="zen"
    PROJECT_STANDBY="zen"
    DB2_VERSION="s12.1.2.0"
    Db2uCluster names can be obtained with the oc get db2ucluster command, in the namespace where the deployments are located. The DB2_VERSION is the version number to which you want to upgrade.
  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 command 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.
    1. Patch the Db2uCluster custom resource to the new version:
      oc patch db2ucluster ${DB2UCLUSTER_STANDBY} -n ${PROJECT_STANDBY} --type merge -p "{\"spec\":{\"version\":\"${DB2_VERSION}\"}}"
      
      The Db2uCluster returns READY when the standby deployment upgrade is complete.
    2. Return the status:
      oc get db2ucluster ${DB2UCLUSTER_STANDBY} -n ${PROJECT_STANDBY}
    3. 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 a READY status.
  4. Switch roles for the standby database to set it as the new primary database:
    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.
    1. Patch the Db2uCluster custom resource to the new version:
      oc patch db2ucluster ${DB2UCLUSTER_PRIMARY} -n ${PROJECT_PRIMARY} --type merge -p "{\"spec\":{\"version\":\"${DB2_VERSION}\"}}"
      The Db2uCluster returns READY when the standby deployment upgrade is complete.
    2. Return the status:
      oc get db2ucluster ${DB2UCLUSTER_PRIMARY} -n ${PROJECT_PRIMARY}
  6. Update the databases.
    1. Update the databases on the current primary (former standby) deployment:
      oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- bash
      su - db2inst1 -s /bin/bash -lc 'db2_update_upgrade --databases --post-upgrade' 
    2. Wait for the log replay to complete.
    3. Ensure that 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
  7. 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.
  8. Complete a role switch to revert back to the original primary deployment by running the following command:
    oc exec -it c-${DB2UCLUSTER_PRIMARY}-db2u-0 -n ${PROJECT_PRIMARY} -- su - db2inst1
    db2 takeover hadr on db ${DBNAME}
  9. Deactivate, then activate the database in the standby deployment by running the following command:
    oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- su - db2inst1
    db2 deactivate db ${DBNAME}
    db2 activate db ${DBNAME}
  10. Start the governor on the primary deployment:
    oc exec -it c-${DB2UCLUSTER_PRIMARY}-db2u-0 -n ${PROJECT_PRIMARY} -- su - db2inst1
    ${HOME}/governor/governor.sh start
  11. Start the governor on the standby deployment:
    oc exec -it c-${DB2UCLUSTER_STANDBY}-db2u-0 -n ${PROJECT_STANDBY} -- su - db2inst1
    ${HOME}/governor/governor.sh start

Results

You have now upgraded your HADR Db2 databases.