Using the Db2 HADR API

The Db2 HADR API provides the interface required to configure and start HADR for two databases that are on the same cluster and in the same Red Hat® OpenShift® project. This API is supported by an OpenShift custom resource definition (CRD).

Configuring the primary and standby databases

When you set up HADR, you must define a primary and standby database. At a minimum, you must specify the Db2uCluster name for both the primary and standby. You can find these names by using the oc get Db2uCluster command.

You can also define the HADR services and specific endpoints to use for the HADR databases. If the services and endpoints do not exist, they will be created for you.

For example,

primary:
   db2uCluster: "db2u-oltp-primary"
   service:
     name: "db2u-oltp-primary-hadr-svc"
     port: 60006
standby:
   db2uCluster: "db2u-oltp-standby"
   service:
     name: "db2u-oltp-standby-hadr-svc"
     port: 60007

Configuring etcd

The Governor service that enables automatic failover of the HADR configuration relies on an etcd key-value store to keep track of the HADR state information, such as the current leader (primary node). A single etcd endpoint must be shared between the two HADR deployments. If these fields are not provided, the default etcd setup is the primary deployment's built-in etcd cluster, but this is meant for development-only environments. Use this setting to define your own etcd cluster.

For example,

etcd: 
   name: "cloud-etc-svc"
   port: 3056

Configuring HADR database configuration parameters

When configuring HADR, you can specify the hadr_timeout, hadr_syncmode, and hadr_peer_window configuration parameters. See HADR configuration parameters for more information.

For example:

dbConfig:
   timeOut: 90
   syncMode: "NEARSYNC"
   peerWindow: 120

Configuring HADR features

When configuring HADR, you can optionally disable automatic client reroute or enable reads on standby. You cannot use automatic client reroute if you enable reads on standby.

Note: Client reroute does not differentiate between writable databases (primary and standard databases) and read-only databases (standby databases). Configuring client reroute between the primary and standby might route applications to the database on which they are not intended to be run.

For example, the following example shows client reroute disabled and reads on standby enabled:

features:
   enableAutomaticClientReroute: false
   enableReadsOnStandby: true

Example of a complete Db2 HADR custom resource definition

The following example shows a complete Db2 HADR custom resource definition:

apiVersion: db2u.databases.ibm.com/v1alpha1
kind: Db2uHadr
metadata:
  name: db2u-oltp-hadr
spec:
  primary:
    db2uCluster: "db2u-oltp-primary"
    service:
      name: "db2u-oltp-primary-hadr-svc"
      port: 60010
  standby:
    db2uCluster: "db2u-oltp-standby"
    service:
      name: "db2u-oltp-standby-hadr-svc"
      port: 60012
  etcd:
    name: "cloud-etc-svc"
    port: 3056
  dbConfig:
    timeOut: 90
    syncMode: "NEARSYNC"
    peerWindow: 120
  features:
    enableAutomaticClientReroute: false
    enableReadsOnStandby: true