Using the Db2 Warehouse 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-wh-primary"
   service:
     name: "db2u-wh-primary-hadr-svc"
     port: 60006
standby:
   db2uName: "db2u-wh-standby"
   service:
     name: "db2u-wh-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 track 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 setup 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 you configure 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 Warehouse on IBM Software Hub 5.2 introduces a role-aware service feature when you configure HADR by using the Db2uHadr custom resource. When this feature is enabled, an extra Kubernetes service is created when the Db2 Warehouse 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 Warehouse operator monitors the HADR role of both deployments in the HADR configuration and updates the label.

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

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

When you configure 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 you configure HADR with the Db2uHadr custom resource, the Db2 Warehouse operator creates Kubernetes services for HADR communication between the primary and standby deployments. In some cloud environments, you might have additional networking layers that require the use of the FQDN pod instead of services to ensure successful Db2 Warehouse validation of hostnames and IP addresses.

advancedOptions:
    hostNameResolutionUsingPodFQDN: "True"