IBM BPM, V8.0.1, All platforms > Install IBM BPM > IBM BPM Standard > Prepare to install the software

Considerations for HADR setup and configuration

Review the following considerations while you plan to set up and configure DB2 for high availability disaster recovery (HADR).

• Verify status of databases for takeover
• Configure data sources for HADR
• Set up programmatic transaction retry properties
• Specify user roles for HADR
• Start the messaging engine after the takeover
• Access additional information

Verify status of databases for takeover

When a site failure occurs, HADR enables the standby database to take over as the primary database, with full DB2 functionality. Before the takeover occurs, verify the DB2 HADR status of both the primary database and the standby database to see if the takeover is allowed or if an error is returned. Sometimes, the takeover might cause an error or might not be allowed.

To check the DB2 HADR status, use the db2pd command.

For example, if you configured a database named MEDB9 with HADR, use the following command to check the status:

db2pd -hadr -db MEDB9

To check the status of all databases, use the following command:

db2pd -hadr -alldbs

See the TAKEOVER HADR command topic. Review the command parameters and the usage notes to determine whether to perform the takeover.

Configure data sources for HADR

Configure the DB2 data sources for HADR in the IBM Business Manager admin console, as described in the Configure client reroute for applications that use DB2 databases topic.

Keep in mind the following considerations when you configure the data sources for IBM BPM products:

• It is recommended to enable the automatic client reroute when setting up DB2 HADR.

• For messaging engine and cell level data sources, the Alternate server names and Alternate port numbers properties must be configured.

• The alternate port must be the external port for the DB2 server, not the HADR service port that is specified in /etc/services.

  For example, if the HADR service port DB2_HADR_1, specified in /etc/services, is 55001, and the DB2 server uses the external port 50000, you must specify port 50000 for the data source alternate port in the admin console.

Set up programmatic transaction retry properties

To support programmatic transaction retries, two new properties have been added to the 00static.xml file, with the following values:

<transaction-reroute-retries>3</transaction-reroute-retries>
<transaction-reroute-retry-delay-in-millis>10000<transaction-reroute-retry-delay-in-millis>

Use the 100Custom.xml configuration file to customize the changes in 00Static.xml if values other than default are required. Complete the following steps:

1. Locate 100Custom.xml configuration file:

   • For a ND environment, the file path is DMGR_profile_root\config\cells\ cell_name\nodes\custom_node_name\servers\ server_name\server_type\config\100Custom.xml.

   • For a stand-alone server environment, the file path is standalone_profile_root\config\cells\ cell_name\nodes\ standalone_node_name\servers\ server_name\server_type\config\100Custom.xml.

2. Edit the 100Custom.xml file. Edit the following section to look like this example:

   <server merge="mergeChildren">
     <transaction-reroute-retries merge="replace">10</transaction-reroute-retries>
     <transaction-reroute-retry-delay-in-millis merge="replace">3000<transaction-reroute-retry-delay-in-millis>
   </server>

3. Save your changes.

Provide all the client reroute properties for all your data sources.

Specify user roles for HADR

When setting up HADR, specify appropriate user roles per platform to determine who can perform different HADR tasks.

• For Windows, use the DB2 administrative user: db2admin

• For Linux, use the DB2 instance user, db2inst1, rather than the administrative user, dasusr1.

For example, if the DB2 instance user is specified, the db2inst1 user backs up the primary database, copies the backup image to the standby server, and then restores or starts the standby server using this image. If the administrative user is specified, the dasusr1 user is the owner of the copied image, which the db2inst1 user who performs the backup and restore actions cannot access. Because the two users belong to different groups and have different access rights to files, the HADR setup might fail.

Start the messaging engine after the takeover

If the auto restart for the messaging engine is disabled, you must manually start the messaging engine after the database takeover occurs.

When two messaging engine servers exist in the same cluster, with messaging server 1 in an active state and messaging engine server 2 in a joined state, you might not have a running messaging engine server in your environment because of the following sequence of events:

1. The database that the messaging engines use has been taken over.

2. Messaging engine server 1 shut down to prevent data loss.

3. Messaging engine server 2 started all the messaging engines and is working as the active server while the messaging engine server 1 is still down.

4. Another takeover of the database occurred.

5. Messaging engine server 2 shut down to prevent data loss.
6. Both messaging engine servers 1 and 2 are down.

Access additional information

If more information is needed, use the following links.

• If an outage occurs in your DB2 HADR environment, see Detecting and responding to system outages in a high availability solution.

• After the failover occurs, if the DB2 HADR status is not peer and if some data loss occurs, configure the DB2 HADR status to peer as described in the following topics:
  • Performing an HADR failover operation
  • Reintegrating a database after a takeover operation

Prepare to install the software

Related concepts:
System requirements

Related tasks:
Preparing operating systems for product installation
Configure Oracle Data Guard for IBM BPM