Using the Db2 HADR API

Quick links

• Configuring the primary and standby databases
• Configuring etcd
• Configuring HADR database configuration parameters
• Configuring HADR features
• HADR advanced options
• Example of a complete Db2uHadr custom resource

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 or Db2uInstance name for both the primary and standby. You can find these names by using the oc get db2ucluster,db2uinstance 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 are created for you.

For example,

primary:
   db2uName: "db2u-oltp-primary"
   service:
     name: "db2u-oltp-primary-hadr-svc"
     port: 60006
standby:
   db2uName: "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

Db2 on IBM Software Hub 5.2 introduces a role-aware service feature when configuring HADR using the Db2uHadr custom resource. When this feature is enabled, an additional Kubernetes service will be created when the Db2 operator configures HADR. This service will always redirect traffic to the current HADR primary deployment by a label on the pod hadr_role=primary. The Db2 operator will monitor the HADR role of both deployments in the HADR configuration and update the label accordingly.

Applications can use the role-aware service c-<Db2uHADR_CR_name>-hadr-primary-svc for Db2 connections instead of enabling ACR.

  features:
    routeToPrimaryService:
      enable: true
      service:
        type: "NodePort"
        name: "my-hadr-svc"

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.

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

features:
   enableAutomaticClientReroute: false
   enableReadsOnStandby: true

HADR advanced options

The hostNameResolutionUsingPodFQDN advanced option allows you to configure HADR with the FQDN pod instead of Kubernetes services.

When configuring HADR with the Db2uHadr custom resource, the Db2 operator will create Kubernetes services for HADR communication between the primary and standby deployments. In some cloud environments, there might be additional networking layers which require the use of the FQDN pod instead of services, to ensure successful Db2 validation of hostnames and IP addresses.

advancedOptions:
    hostNameResolutionUsingPodFQDN: "True"