Configuring the HADR API for the Db2 service

You can set up a Db2 high availability disaster recovery (HADR) configuration between databases that are on the same cluster and in the same Red Hat® OpenShift® project.

Before you begin

Ensure you have the etcd endpoint (IP/name and port) available for HADR setup. See step 5 of Setting up an etcd store for HADR in Db2.
Part of the setup process involves sharing the database backup image and keystore tar file between the primary and standby databases, as described in Step 5. You can perform this step either by creating a dynamically provisioned persistent volume or by using rsync to copy assets. If you are deploying Db2 for the purpose of using HADR, it can be beneficial to use a volume that is shared between the primary and standby databases. In this case, you need to create the volume when you deploy Db2. If you are setting up HADR on existing databases, using rsync might be preferable.
Preserve your existing backup images.
Important: When you start an HADR configuration, the backup images that are in the ${BACKUPDIR} path are deleted. To preserve the existing backup images, move the images to a subdirectory under ${BACKUPDIR}. For example, ${BACKUPDIR}/backup_001.

About this task

After both Db2 services are deployed, follow these steps to set up the HADR configuration by using the Db2 HADR API, which is implemented by using an OpenShift custom resource definition (CRD).

Notes:

This procedure can only be used for two deployments that are in the same OpenShift project in the same cluster.
This method cannot be used for deployments on IBM® Cloud. To configure HADR, use the HADR scripts instead.

Procedure

Create a YAML file for the HADR custom resource definition on one of the master nodes and save the file, for example as /tmp/db2u_hadr.yaml.
The following example shows the minimum fields that are required. You can set additional options by using the Db2 HADR API.
```
apiVersion: db2u.databases.ibm.com/v1alpha1
kind: Db2uHadr
metadata:
  name: example-hadr
spec:
  primary:
    db2uCluster: "db2u-oltp-1"
  standby:
    db2uCluster: "db2u-oltp-2"
  etcd:
    name: "cloud-etc-svc"
    port: 3056
```
You can use the oc get Db2uCluster command to get the names for the db2uCluster keyword.
Note: You can exclude the etcd fields in a development-only environment. In this case, the HADR setup uses the primary deployment's built-in etcd. See Setting up an etcd store for HADR in Db2 for important considerations regarding this step.
Run the following command to create the CRD.
```
oc create -f /tmp/db2u_hadr.yaml
```
List the CRD:
```
oc get Db2uHadr
```

Use the following command to monitor the status of the CRD:

oc get db2uhadr db2u-oltp-hadr -oyaml | awk '/^status:/,/hadrSettings:/'

Here is an example status:

status:
  conditions:
  - lastTransitionTime: "2020-10-21T23:16:33Z"
    message: Creating Db2u HADR configuration file on Standby
    status: "False"
    type: Creating Db2u HADR configuration files
  - lastTransitionTime: "2020-10-21T23:17:37Z"
    message: Done
    status: "True"
    type: Setting up Primary database copy for HADR

After you see a similar status message, proceed to the next step.

Share the database backup image and keystore tar file between the primary and standby databases. You can perform this step in two ways:
- Create a dynamically provisioned persistent volume
  This volume is shared between the primary and standby databases. This volume is used by the CRD to share the database backup and keystore tar file. See Deploying a Db2 HADR configuration by using a shared volume for backup storage for details.
- Use rsync to copy assets to the standby deployment
  When type: Setting up Primary database copy for HADR reaches the status "True", start copying the backup image and keystore tar file into the backup directory on the standby deployment.
  
  For example, the following two commands copy the assets from a directory on the host called /tmp/hadr on the primary database to the standby database:
```
oc rsync path_to_backup /tmp/hadr
oc rsync /tmp/hadr/ path_to_backup
```

Results

When the CRD status phase shows as Completed, the HADR setup is complete, automatic client reroute is enabled, and HADR is started.

You can periodically issue the oc get db2uhadr command to monitor the status. The following examples show the command results, and then the CRD status when HADR setup is complete:

NAME             HADR PRIMARY               HADR STANDBY               STATE      AGE
db2u-oltp-hadr   db2u-oltp-1                db2u-oltp-1                Complete   7m8s

status:
  conditions:
  - lastTransitionTime: "2020-11-12T20:10:47Z"
    message: Creating Db2u HADR configuration file on Standby
    status: "False"
    type: Creating Db2u HADR configuration files
  - lastTransitionTime: "2020-11-12T20:12:54Z"
    message: Done
    status: "True"
    type: Enabling ACR feature for HADR
  - lastTransitionTime: "2020-11-12T20:12:56Z"
    message: Done
    status: "True"
    type: Setting up Db2u HADR completed
  - lastTransitionTime: "2020-11-12T20:11:33Z"
    message: Done
    status: "True"
    type: Setting up Primary database copy for HADR
  - lastTransitionTime: "2020-11-12T20:12:10Z"
    message: Done
    status: "True"
    type: Setting up Standby database copy for HADR
  - lastTransitionTime: "2020-11-12T20:12:46Z"
    message: Done
    status: "True"
    type: Starting HADR on the Primary database copy
  - lastTransitionTime: "2020-11-12T20:10:45Z"
    message: Setting up Db2u HADR completed
    status: "False"
    type: latestPhase
  hadrSettings: