HADR

The easiest way to understand HADR is as a pair of servers that are kept in sync with each other at the database level.

Hence, you will define your DB2 datasource in the same manner as if you were not using HADR.

If, in the event, the connectivity between the pair is lost you can set a timeout period for HADR to turn off.

Only data changes are required to be replicated, so read transaction are unaffected by the implementation of HADR.

You could also mingle automatic client reroute technique with the HADR databases.

If any of these parameters are empty or misconfigured, DB2 HADR servers will not start properly.

DB2 HADR also increases availability by allowing you to perform rolling upgrades.

To take advantage of HADR, you must have two dedicated servers available: one for the primary database and one for the standby database.

Once HADR is turned off, the primary can continue to process transactions normally.

On the standby machine, first deactivate the database and then issue the start hadr command to start it as the standby database (Listing 7).

On the primary machine, first activate the database and then issue the start hadr command to start it as the primary database (Listing 8).

Assign appropriate values to the HADR configuration parameters for both the primary and the standby database.

The failover operation for HADR can be automated using HA software.

With HADR, a failover occurs and the standby database takes over, replacing the failed primary database in seconds.

Connect to the standby database and start HADR on the standby server by executing the START HADR command.

Connect to the primary database and start HADR on the primary server with the START HADR command.

The basic method by which HADR replicates data is to send DB2 log writes simultaneously to the local disk and to the standby system.

If the primary and standby databases are not identical when HADR is started, an error will occur.

A DB2 HADR scenario consists of two DB2 systems, a primary and a standby.

Setup and administration of HADR is very simple and DB2 provides a wizard to help with these tasks.

If there are two network interfaces on each host, a private network can be set up exclusively for HADR replication.

If a server has multiple network interfaces, ensure that the HADR host name or IP address maps to the intended interface.

It is critical that all the HADR parameters be set with proper values prior to starting DB2 HADR on either the primary or standby machine.

Only DDL copymode is supported for high availability disaster recovery (HADR) databases.

Configure the HADR variables for each database on the primary machine.

Later, it is decided to switch the database to HADR-enabled DB2.

Under the HADR status role, you will see "Standby" for the standby machine and "Primary" for the primary machine.

In the event you want to perform some type of system maintenance task, upgrade, or DB2 fix installation, you can turn HADR off.

Once the databases are in peer mode, the DB2 HADR servers on the primary and standby machines are ready for use.

Figure 5 illustrates the HADR processes synchronizing a primary and standby system.

In addition, DB2 HADR needs to be started on the standby machine first, before it is started on the primary machine.

For example, a DB2 HADR (High Availability Disaster Recovery) cluster can be set up in the cloud.

SQL30081N A communication error has been detected when starting HADR on the primary or standby machine.

Issue the following commands on the standby server for a DB2 HADR takeover to occur (Listing 9).

Now, since you are done with the entire HADR setup, verify whether it is really working.

NODE3: This machine is the HADR standby server for DB2 failover and does not fall under the TSA cluster domain setup.

The primary and standby database name for the HADR setup is jsbmain.

HADR provides for synchronous replication of all logged DB2 operations.

In these circumstances, there is little to no impact of running HADR.

The overhead of running HADR is very small.

It is responsible for monitoring entities such as network interfaces, DB2 instances, and HADR databases.

For your reference, here is a collection of causes and solutions for some of the possible problems that you might encounter using DB2 HADR

Check the required HADR variables below (see Listing 3). They must be correct and cannot be empty

On the primary server (Node1), execute the following command from the db2 CLP to enable the automatic client reroute feature of HADR

Step 9: Testing failover of HADR

High Availability Disaster Recovery (for example, HADR log delay; this category is new to DB2 V8. 2)