Autom Ating HADR On DB2 10.1 For Linux, UNIX and Windows Failover Solution Using Tivoli System Automation For Multiplatforms

Automating HADR on DB2 10.
1 for
Linux, UNIX and Windows Failover
Solution Using Tivoli System
Automation for Multiplatforms
August 2014
Authors:
Phil Stedman, IBM Toronto Lab (pmstedma@us.ibm.com)
Paul Lee, IBM Toronto Lab (hylee@ca.ibm.com)
Table of Contents
1. Introduction and Overview ................................................................................................ 1
2. Before you begin ................................................................................................................... 2
2.1 Knowledge Prerequisites.............................................................................................. 2
2.2 Hardware Configuration Used in Setup .................................................................. 2
2.3 Software Version used in Setup ................................................................................ 2
3. Overview of Important Concepts .................................................................................... 3
3.1 The db2haicu utility ....................................................................................................... 3
3.2 HADR Overview ............................................................................................................... 3
3.3 Typical HADR topologies .............................................................................................. 3
4. Setting up an automated multiple network HADR topology using db2haicu
Interactive mode ........................................................................................................................ 4
4.1 Topology Configuration ................................................................................................. 4
4.1.1 Basic Network Setup ............................................................................................. 6
4.1.2 HADR Database Setup .......................................................................................... 7
4.1.3 Cluster Preparation .............................................................................................. 12
4.1.4 Network Time Protocol ....................................................................................... 12
4.1.5 Client Reroute ........................................................................................................ 12
4.2 The db2haicu Interactive setup mode .................................................................. 14
4.2.1 Setup Procedures on Standby Machine........................................................ 15
4.2.2 Setup Procedures on Primary Machine......................................................... 21
5. Setting up an automated single network HADR topology using the db2haicu
XML mode.................................................................................................................................... 25
6. Post Configuration Testing ............................................................................................... 32
6.1 The “Power off” test .................................................................................................... 35
6.2 Deactivating the HADR database ........................................................................... 39
6.3 DB2 Failure Test ............................................................................................................ 41
6.4 Manual Instance Control through db2stop and db2start .............................. 45
7. Maintenance .......................................................................................................................... 47
7.1 Disabling High Availability ......................................................................................... 47
7.2 Manual Takeover ........................................................................................................... 50
7.3 db2haicu Maintenance mode ................................................................................... 51
8. Multiple Standby HADR in DB2 Version 10.1 ........................................................... 54
8.1 Setup for Multiple Standby HADR .......................................................................... 54
8.2 Setting up an automated Multiple Standby HADR topology using db2haicu
.................................................................................................................................................... 56
9. Troubleshooting ................................................................................................................... 57
9.1 Unsuccessful Failover .................................................................................................. 57
9.2 db2haicu ‘-delete’ option ........................................................................................... 58
9.3 The “syslog” and the DB2 server diagnostic log file (db2diag.log) ........... 58
1. Introduction and Overview
This paper describes two distinct configurations of an automated IBM® DB2® for
Linux®, UNIX®, and Windows® failover solution. The configurations will be based
on the DB2 High Availability Disaster Recovery (HADR) feature and the DB2 High
Availability Instance Configuration Utility (db2haicu) available with DB2 Version
10.1 software release.
Target Audience for this paper:

• DB2 database administrators
• UNIX system administrators
1
2. Before you begin
Below you will find information on knowledge requirements, as well as hardware

and software configurations used to set up the topology covered in this paper. It is
important that you read this section prior to beginning any setup.
2.1 Knowledge Prerequisites

• Basic understanding of DB2 Version 10.1 and HADR*
• Basic understanding of Tivoli® System Automation (TSA) cluster manager
software**
• Basic understanding of AIX operating system concepts
*Information on DB2 HADR can be found here:

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.lu
w.admin.ha.doc/doc/c0011748.html
**Information on TSA can be found here:

http://www.ibm.com/software/tivoli/products/sys-auto-linux/
2.2 Hardware Configuration Used in Setup

For the topology covered in this paper, the following hardware configuration was
used:
• Two machines each with:
o CPU = 2 CPU, 2 GHz each
o Network Adapters = 10/100Mbps Virtual I/O Ethernet Adapter
o Memory = 16 GB
2.3 Software Version used in Setup

For the topology covered in this paper, the following software configuration was
used:
 DB2 Version 10.1
 AIX 6.1 TL7 SP3
 SA MP 3.2.2.1
2
3. Overview of Important Concepts
3.1 The db2haicu utility

db2haicu is a tool available with DB2 Version 10.1 and stands for the “DB2 High
Availability Instance Configuration Utility”. This utility takes in user input regarding
the software and hardware environment of a DB2 instance, and configures the
instance for High Availability using the TSA Cluster Manager. During this
configuration process, all necessary resources, dependencies and equivalencies are
automatically defined to TSA. Note: TSA does not need to be manually installed on
your system as it is prepackaged with DB2 Version 10.1.
Two input methods can be used to provide the necessary data to db2haicu. The first
method is the interactive mode, where the user is prompted for input at the
command line. The second input method is the XML mode, where db2haicu can
parse the necessary data from a user defined XML file.
The db2haicu interactive mode is covered in Section 4 and the db2haicu XML mode
is covered in Section 5.
3.2 HADR Overview

The High Availability Disaster Recovery (HADR) feature of DB2 Version 10.1 allows
a Database Administrator (DBA) to have one “hot standby” copy of any DB2
database; such that, in the event of a primary database failure, a DBA can quickly
switch over to the “hot standby” with minimal interruption to database clients. (See
Fig.1 below for a typical HADR environment.)
However, an HADR primary database does not automatically switch over to its
standby database in the event of failure. Instead, a DBA must manually perform a
takeover operation when the primary database has failed.
The db2haicu tool can be used to automate such an HADR system. During the
db2haicu configuration process, the necessary HADR resources and their
relationships are defined to the cluster manager. Failure events in the HADR system
can then be detected automatically and takeover operations can be executed
without manual intervention.
3.3 Typical HADR topologies

A typical HADR topology contains two hosts – a primary host (e.g., hadr01) to host
the primary HADR database, and a standby host (e.g., hadr02) to host the standby
HADR database. The hosts are connected to one another over a network to
accommodate log shipping between the two databases.
3
4. Setting up an automated multiple network HADR
topology using db2haicu Interactive mode
The configuration of an automated single network HADR topology, as illustrated in

Fig. 1, is described in the steps below.
Notes:
1. There are two parts to this configuration. The first part describes the preliminary
steps needed to configure a multiple network HADR topology. The second part
describes the use of db2haicu’s interactive mode to automate the topology for
failovers.
2. The parameters used for various commands described below are based on the
topology illustrated in Fig. 1. You must change the parameters to match your own
specific environment.
4.1 Topology Configuration

This topology makes use of two hosts: the primary host (e.g., hadr01) to host the
primary HADR database and the standby host (e.g., hadr02) to host the standby
HADR database.
The hosts are connected to one another using two distinct networks: a public
network and a private network. The public network is defined to host the virtual IP
address that allows clients to connect to the primary database. The private network
is defined to carry out HADR replication between the primary and standby nodes.
4
Fig 1. Automated Single Network HADR Topology
5
4.1.1 Basic Network Setup
The two machines used for this topology contain two network interfaces each. The
network adapters are named en0 and en1 (same naming on each machine). We will
take it that en0 is the ‘public’ adapter (connected to the public network) and en1 is
the ‘private’ adapter (commonly only connected to the other node in the cluster).
Note that for Linux, the adapters are generally named eth0 (and eth1), and for
Solaris, adapters are generally named hme0 (and hme1).
1. The en0 network interfaces are connected to each other through the external
network cloud forming the public network. We assigned the following static IP
addresses to the en0 adapters on the primary and standby hosts:
Primary (hadr01)
en0: 9.23.2.124 (255.255.255.0)
Standby (hadr02)
en0: 9.23.2.198 (255.255.255.0)
2. The en1 network interfaces are connected to each other using a switch forming a
private network. The following static IP addresses are assigned to the en1 network
interfaces:
Primary (hadr01)
en1: 192.168.100.3 (255.255.255.0)
Standby (hadr02)
en1: 192.168.100.4 (255.255.255.0)
3. Make sure that the primary and standby host names are mapped to their
corresponding public IP addresses in the /etc/hosts file:
9.23.2.124 hadr01.fullyQualifiedDomain.com hadr01

9.23.2.198 hadr02.fullyQualifiedDomain.com hadr02
Confirm that the above two lines are present in the /etc/hosts file on both machines.
4. Make sure that the file ~/sqllib/db2nodes.cfg for the instance residing on the
machine hadr01 has contents as follows:
0 hadr01 0
Then ensure that the file ~/sqllib/db2nodes.cfg for the instance residing on the
machine hadr02 has contents as follows:
0 hadr02 0
6
5. The primary and the standby machines should be able to ping each other. Issue
the following commands on both the primary and the standby machines and make
sure that they complete successfully:
$ ping hadr01
$ ping hadr02
$ ping 192.168.100.3
$ ping 192.168.100.4
4.1.2 HADR Database Setup

We create a primary DB2 instance named ‘db2inst1’ on the primary host, and a
standby instance ‘db2inst1’ on the standby host.
1. Create the HADR database named “HADRDB” on the Primary instance ‘db2inst1’
and update the db cfg 'LOGARCHMETH1' and 'LOGINDEXBUILD' parameters for
HADRDB to a path.
(db2inst1@hadr01) /home/db2inst1
$ db2 create db hadrdb on /db1/db2inst1
DB20000I The CREATE DATABASE command completed successfully.
$ db2 update db cfg for hadrdb using LOGARCHMETH1 DISK:/db1/db2inst1/logarchmeth1/
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
$ db2 update db cfg for hadrdb using LOGINDEXBUILD ON
2. Update the following parameters on the Primary instance ‘db2inst1’ to configure

the HADR pair.
$ db2 get db cfg for hadrdb | grep -i hadr
Database Configuration for Database hadrdb
HADR database role = STANDARD
HADR local host name (HADR_LOCAL_HOST) = 192.168.100.3
HADR local service name (HADR_LOCAL_SVC) = 55555
HADR remote host name (HADR_REMOTE_HOST) = 192.168.100.4
HADR remote service name (HADR_REMOTE_SVC) = 55565
HADR instance name of remote server (HADR_REMOTE_INST) = db2inst1
HADR timeout value (HADR_TIMEOUT) = 120
HADR target list (HADR_TARGET_LIST) =
HADR log write synchronization mode (HADR_SYNCMODE) = SYNC
HADR spool log data limit (4KB) (HADR_SPOOL_LIMIT) =0
HADR log replay delay (seconds) (HADR_REPLAY_DELAY) =0
HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 300
7
3. Back up the database HADRDB to a path which is accessible from both machines.
$ db2 backup db HADRDB to /TMP/qiaochu/PAPER
Backup successful. The timestamp for this backup image is : 20120611112542
4. On the Standby instance, restore the database HADRDB.
$ db2 restore db HADRDB from /TMP/qiaochu/PAPER taken at 20120611112542 to /db1/db2inst1
DB20000I The RESTORE DATABASE command completed successfully.
5. Update the following parameters on the Standby instance ‘db2inst1’ to configure

the HADR pair.
$ db2 get db cfg for hadrdb | grep -i hadr
Database Configuration for Database hadrdb
HADR database role = STANDARD
HADR local host name (HADR_LOCAL_HOST) = 192.168.100.4
HADR local service name (HADR_LOCAL_SVC) = 55565
HADR remote host name (HADR_REMOTE_HOST) = 192.168.100.3
HADR remote service name (HADR_REMOTE_SVC) = 55555
HADR instance name of remote server (HADR_REMOTE_INST) = db2inst1
HADR timeout value (HADR_TIMEOUT) = 120
HADR target list (HADR_TARGET_LIST) =
HADR log write synchronization mode (HADR_SYNCMODE) = SYNC
HADR spool log data limit (4KB) (HADR_SPOOL_LIMIT) =0
HADR log replay delay (seconds) (HADR_REPLAY_DELAY) =0
HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 300
A) Note that the configuration values HADR_REMOTE_HOST and

HADR_LOCAL_HOST on the standby and primary databases reflect the IP addresses
assigned to the en1 NICs.
B) Set the HADR_PEER_WINDOW configuration parameter to a large enough value

to ensure that the HADR peer window does not expire before the standby machine
attempts to take over the HADR primary role. In our environment, 300 seconds was
sufficient to ensure this.
C) The HADR_SYNCMODE was set to ‘SYNC’ and will be used for both examples in
this paper. For further details concerning the HADR synchronization modes, consult
the DB2 documentation. Note: Only the ‘SYNC’ and ‘NEARSYNC’ synchronization
modes are supported in an automated HADR configuration
8
6. It is recommended to enable the BLOCKNONLOGGED database configuration
parameter for HADR databases. This can be achieved by running the following
command from both the primary and standby hosts:
$ db2 update db cfg for HADRDB using BLOCKNONLOGGED YES
$ db2 update db cfg for HADRDB using BLOCKNONLOGGED YES
7. We must make sure that the HADR databases are in “peer” state before
proceeding with the db2haicu tool. Start HADR on the database pair by issuing the
following commands from the standby and primary instances:
$ db2 start hadr on db HADRDB as standby
DB20000I The START HADR ON DATABASE command completed successfully.
$ db2 start hadr on db HADRDB as primary
DB20000I The START HADR ON DATABASE command completed successfully.
Issue the following command to check HADR status on either the primary or the
standby instance:
db2pd –hadr –db <database name>
You should see something similar to the output illustrated below.
9
Standby:
$ db2pd -hadr -db hadrdb
Database Member 0 -- Database HADRDB -- Standby -- Up 0 days 00:02:46 -- Date

2012-06-11-11.53.05.812993
HADR_ROLE = STANDBY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = SYNC
STANDBY_ID = 0
LOG_STREAM_ID = 0
HADR_STATE = PEER
PRIMARY_MEMBER_HOST = hadr01
PRIMARY_INSTANCE = db2inst1
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = hadr02
STANDBY_INSTANCE = db2inst1
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 06/11/2012 11:50:33.407143 (1339429833)
HEARTBEAT_INTERVAL(seconds) = 30
HADR_TIMEOUT(seconds) = 120
TIME_SINCE_LAST_RECV(seconds) = 2
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.001843
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.240
LOG_HADR_WAIT_COUNT = 130
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 262088
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 262088
PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 61, 41010383
STANDBY_LOG_FILE,PAGE,POS = S0000000.LOG, 61, 41010383
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000000.LOG, 61, 41010383
STANDBY_RECV_REPLAY_GAP(bytes) = 2443353
PRIMARY_LOG_TIME = 06/11/2012 11:52:25.000000 (1339429945)
STANDBY_LOG_TIME = 06/11/2012 11:52:25.000000 (1339429945)
STANDBY_REPLAY_LOG_TIME = 06/11/2012 11:52:25.000000 (1339429945)
STANDBY_RECV_BUF_SIZE(pages) = 4298
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 0
PEER_WINDOW(seconds) = 300
PEER_WINDOW_END = 06/11/2012 11:58:03.000000 (1339430283)
READS_ON_STANDBY_ENABLED = N
10
Primary:
$ db2pd -hadr -db hadrdb
Database Member 0 -- Database HADRDB -- Active -- Up 0 days 00:06:28 -- Date 2012-06-11-11.56.59.648102
HADR_ROLE = PRIMARY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = SYNC
STANDBY_ID = 1
LOG_STREAM_ID = 0
HADR_STATE = PEER
PRIMARY_MEMBER_HOST = hadr01
PRIMARY_INSTANCE = db2inst1
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = hadr02
STANDBY_INSTANCE = db2inst1
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 06/11/2012 11:50:33.587433 (1339429833)
HEARTBEAT_INTERVAL(seconds) = 30
HADR_TIMEOUT(seconds) = 120
TIME_SINCE_LAST_RECV(seconds) = 25
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.001843
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.240
LOG_HADR_WAIT_COUNT = 130
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 262088
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 262088
PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 61, 41010383
STANDBY_LOG_FILE,PAGE,POS = S0000000.LOG, 61, 41010383
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000000.LOG, 61, 41010383
STANDBY_RECV_REPLAY_GAP(bytes) = 1018063
PRIMARY_LOG_TIME = 06/11/2012 11:52:25.000000 (1339429945)
STANDBY_LOG_TIME = 06/11/2012 11:52:25.000000 (1339429945)
STANDBY_REPLAY_LOG_TIME = 06/11/2012 11:52:25.000000 (1339429945)
STANDBY_RECV_BUF_SIZE(pages) = 4298
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 0
PEER_WINDOW(seconds) = 300
PEER_WINDOW_END = 06/11/2012 12:01:33.000000 (1339430493)
READS_ON_STANDBY_ENABLED = N
11
4.1.3 Cluster Preparation
Before using the db2haicu tool, the primary and the standby nodes must be
prepared with the proper security environment.
1) With root authority, issue the following command on both the primary and
the standby hosts:
(root@hadr01) $ preprpnode hadr01 hadr02

(root@hadr02) $ preprpnode hadr01 hadr02
This command only needs to be run once per host and not for every DB2 instance
that is made highly available.
4.1.4 Network Time Protocol

The time and dates on the standby and the primary machines should be
synchronized as closely as possible. This is absolutely critical to ensure smooth
failovers during primary machine failures.
The Network time protocol can be used for this purpose. Refer to your operating
system documentation for information on how to configure NTP for your system.
Configure NTP for both the primary and standby database hosting machines.
4.1.5 Client Reroute

There are two methods by which DB2 client applications can be automatically routed
to the HADR primary database location:
Method #1: Configuring a virtual IP address for the HADR database via the db2haicu
utility, see the “Virtual IP Address setup” portion of section 4.2.2 for more details.
Method #2: Enabling automatic client reroute (ACR) by updating the database’s
alternate server information. See below for more details.
Automatic Client Reroute (ACR)

The ACR feature allows DB2 client applications to recover from a lost database
connection in the case of a network failure. In order to accomplish this, we set the
alternate server of the Primary instance to be the Standby and vice versa. This
allows client connections to get automatically rerouted to the other machine in the
case of a HADR role switch, i.e. takeover. Steps for setting up client reroute are
shown below:
12
1. Issue the following commands on the standby and the primary instances to
configure the pair for client reroute:
$ db2 update alternate server for database hadrdb using hostname 9.23.2.198 port 50504
$ db2 update alternate server for database hadrdb using hostname 9.23.2.124 port 50504
The IP 9.23.2.198 maps to the Standby machine and the IP 9.23.2.124 maps to the
Primary machine. The port number 50504 matches the DBM CFG 'SVCENAME'
parameter value of db2inst1 on both hosts.
2. The client reroute configuration can then be validated as follows:
Primary - (db2inst1@hadr01) /home/db2inst1

$ db2 connect to HADRDB
$ db2 connect reset
Standby - (db2inst1@hadr02) /home/db2inst1
$ db2 takeover hadr on db HADRDB
$ db2 connect to HADRDB
$ db2 connect reset
Primary – (db2inst1@hadr01) /home/db2inst1
$ db2 takeover hadr on db HADRDB
After this, we can list the database directory to verify that the alternate server has
been configured successfully:
$ db2 list db directory

System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = HADRDB
Database name = HADRDB
Local database directory = /db1/db2inst1
Database release level = f.00
Comment =
Directory entry type = Indirect
Catalog database partition number =0
Alternate server hostname = 9.23.2.124
Alternate server port number = 50504
13
4.2 The db2haicu Interactive setup mode
After the preceding preliminary configuration steps are completed, the db2haicu
tool can be used to automate HADR failover.
Db2haicu must be run first on the standby instance and then on the primary
instance for the configuration to complete. The details involving the process are
outlined in the following section.
Note: The “...” above a db2haicu message indicates continuation from a message
displayed in a previous step.
14
4.2.1 Setup Procedure on Standby Machine
Creating a Cluster Domain
Log on to the standby instance and issue the “db2haicu” command. The following
welcome message will be displayed on the screen:
$ db2haicu
Welcome to the DB2 High Availability Instance Configuration Utility (db2haicu).
You can find detailed diagnostic information in the DB2 server diagnostic log file called db2diag.log. Also,
you can use the utility called db2pd to query the status of the cluster domains you create.
For more information about configuring your clustered environment using db2haicu, see the topic called 'DB2
High Availability Instance Configuration Utility (db2haicu)' in the DB2 Information Center.
db2haicu determined the current DB2 database manager instance is 'db2inst1'. The cluster configuration that
follows will apply to this instance.
db2haicu is collecting information on your current setup. This step may take some time as db2haicu will need
to activate all databases for the instance to discover all paths ...
When you use db2haicu to configure your clustered environment, you create cluster domains. For more
information, see the topic 'Creating a cluster domain with db2haicu' in the DB2 Information Center. db2haicu
is searching the current machine for an existing active cluster domain ...
db2haicu did not find a cluster domain on this machine. db2haicu will now query the system for information
about cluster nodes to create a new cluster domain ...
db2haicu did not find a cluster domain on this machine. To continue configuring your clustered environment
for high availability, you must create a cluster domain; otherwise, db2haicu will exit.
Create a domain and continue? [1]

1. Yes
2. No
15
1) We must now create a cluster domain. Type ‘1’ and press “Enter” at the following
initial prompt.
...
Create a domain and continue? [1]
1. Yes
2. No
1
2) Enter a unique name for the domain you want to create and the number of hosts
contained in the domain (2 in our case). We decided to name our domain
“hadr_domain”.
...
Create a unique name for the new domain:
hadr_domain
Nodes must now be added to the new domain.
How many cluster nodes will the domain 'hadr_domain' contain?
2
3) Follow the prompts to enter the name of the primary and the standby hosts and
confirm domain creation.
Enter the host name of a machine to add to the domain:

hadr01
Enter the host name of a machine to add to the domain:
hadr02
db2haicu can now create a new domain containing the 2 machines that you specified. If you choose not to
create a domain now, db2haicu will exit.
Create the domain now? [1]

1. Yes
2. No
1
Creating domain 'hadr_domain' in the cluster ...
Creating domain 'hadr_domain' in the cluster was successful.
16
Quorum Configuration
After the domain creation has completed, a quorum must be configured for the
cluster domain. The supported quorum type for this solution is a “network quorum”.
A network quorum is a pingable IP address that is used to decide which host in the
cluster will serve as the “active” host during a site failure, and which hosts will be
offline.
You will be prompted by db2haicu to enter quorum configuration values:
You can now configure a quorum device for the domain. For more information, see the topic "Quorum
devices" in the DB2 Information Center. If you do not configure a quorum device for the domain, then a
human operator will have to manually intervene if subsets of machines in the cluster lose connectivity.
Configure a quorum device for the domain called 'hadr_domain'? [1]

1. Yes
2. No
From the preceding prompt:

1) Type ‘1’ and press “Enter” to create the quorum
...
The following is a list of supported quorum device types:
1. Network Quorum
Enter the number corresponding to the quorum device type to be used: [1]
1
2) Type ‘1’ and press Enter again to choose the Network Quorum type. Then, follow
the prompt to enter the IP address you would like to use as a network tiebreaker.
...
Specify the network address of the quorum device:
9.23.2.246
Configuring quorum device for domain 'hadr_domain' ...
Configuring quorum device for domain 'hadr_domain' was successful.
The cluster manager found the following total number of network interface cards on the machines in the cluster
domain: '2'. You can add a network to your cluster domain using the db2haicu utility.
Quorum configuration is now completed. Note that you may use any IP address as
the quorum device, so long as the IP address is pingable from both hosts. Use an IP
address that is known to be reliably available on the network. The IP address of the
DNS server is usually a reasonable choice here.
17
Network Setup
After the quorum configuration, you must define the network(s) of your system to
db2haicu. If network failure detection is important to your configuration, you must
follow the prompts and add the networks to the cluster at this point. All network
interfaces are automatically discovered by the db2haicu tool.
An example is illustrated below:
a) public network setup

Create networks for these network interface cards? [1]
1. Yes
2. No
1
Enter the name of the network for the network interface card: 'en0' on cluster node: 'hadr01'
1. Create a new public network for this network interface card.
2. Create a new private network for this network interface card.
Enter selection:
1
Are you sure you want to add the network interface card 'en0' on cluster node 'hadr01' to the network
'db2_public_network_0'? [1]
1. Yes
2. No
1
Adding network interface card 'en0' on cluster node 'hadr01' to the network 'db2_public_network_0' ...
Adding network interface card 'en0' on cluster node 'hadr01' to the network 'db2_public_network_0' was
successful.
1. db2_public_network_0
Enter selection:
1
'db2_public_network_0'? [1]
1. Yes
2. No
1
successful.
18
b) private network setup
Enter selection:
3
'db2_private_network_0'? [1]
1. Yes
2. No
1
Adding network interface card 'en1' on cluster node 'hadr01' to the network 'db2_private_network_0' ...
Adding network interface card 'en1' on cluster node 'hadr01' to the network 'db2_private_network_0' was
successful.
2. db2_private_network_0
Enter selection:
2
'db2_private_network_0'? [1]
1. Yes
2. No
1
Adding network interface card 'en1' on cluster node 'hadr02' to the network 'db2_private_network_0' ...
Adding network interface card 'en1' on cluster node 'hadr02' to the network 'db2_private_network_0' was
successful.
Note that it is not possible to add two NICs with assigned IP addresses that reside on
different subnets to the same common network. For example, in this configuration,
if one tries to define en1 and en0 to the same network using db2haicu, the input will
be rejected.
19
Cluster Manager Selection
After the network definitions, db2haicu prompts for the Cluster Manager software
being used for the current HA setup.
For our purposes, we select TSA:
Retrieving high availability configuration parameter for instance 'db2inst1' ...

The cluster manager name configuration parameter (high availability configuration parameter) is not set. For
more information, see the topic "cluster_mgr - Cluster manager name configuration parameter" in the DB2
Information Center. Do you want to set the high availability configuration parameter?
The following are valid settings for the high availability configuration parameter:
1.TSA
2.Vendor
Enter a value for the high availability configuration parameter: [1]
1
Setting a high availability configuration parameter for instance 'db2inst1' to 'TSA'.
Adding DB2 database partition '0' to the cluster ...
Adding DB2 database partition '0' to the cluster was successful.
db2haicu will automatically add the DB2 single partition instance running the
standby HADR database to the specified Cluster Manager at this point.
Automate HADR failover

Right after the DB2 standby single partition instance resource has been added to the
cluster domain, the user will be prompted to confirm automation for the HADR
database.
Do not validate and automate HADR failover on the Standby machine since the
database partition resource on the Primary is not yet created. Answer “No” for now.
Do you want to validate and automate HADR failover for the HADR database 'HADRDB'? [1]
1. Yes
2. No
2
All cluster configurations have been completed successfully. db2haicu exiting ...
20
4.2.2 Setup Procedure on Primary Machine
Cluster Manager Selection

Log on to the primary instance and issue the “db2haicu” command. The following
message will be displayed on the screen. Select “TSA” as the cluster manager:
$ db2haicu
db2haicu found a cluster domain called 'hadr_domain' on this machine. The cluster configuration that follows
will apply to this domain.

1.TSA
2.Vendor
1
21
Automate HADR failover
At this point, you can now select to validate and automate HADR failover for the
database:
Do you want to validate and automate HADR failover for the HADR database 'HADRDB'? [1]
1. Yes
2. No
1
Adding HADR database 'HADRDB' to the domain ...
Adding HADR database 'HADRDB' to the domain was successful.
Virtual IP address setup

At this point, you have the option of creating and associating a virtual IP address
with your HADR database for the purpose of automatic client routing. If ACR is the
preferred method then there is no need to create a virtual IP address:
Do you want to configure a virtual IP address for the HADR database 'HADRDB'? [1]
1. Yes
2. No
2
However, if making use of a virtual IP address is the preferred method of achieving

automatic client routing, then it can be configured as follows:
Do you want to configure a virtual IP address for the HADR database 'HADRDB'? [1]
1. Yes
2. No
1
Enter the virtual IP address:
9.23.2.176
Enter the subnet mask for the virtual IP address 9.23.2.176: [255.255.255.0]
255.255.255.0
Select the network for the virtual IP 9.23.2.176:
Enter selection:
1
Adding virtual IP address 9.23.2.176 to the domain …
Adding virtual IP address 9.23.2.176 to the domain was successful.
Note that the IP address that you select must be reserved by the network
administrator exclusively for the use of this configuration, and must not already be
assigned to any existing computer on the network. Verify that the IP address
selected is not pingable, reachable, or present on the network in any way. In
addition, this IP address must be routable from both hosts.
22
The Automated Cluster controlled HADR configuration is complete. Issue the
“lssam” command to review the state of the cluster resources:
Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Nominal=Online

'- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs
|- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr01
'- Offline IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr02
Online IBM.ResourceGroup:db2_db2inst1_hadr01_0-rg Nominal=Online
'- Online IBM.Application:db2_db2inst1_hadr01_0-rs
'- Online IBM.Application:db2_db2inst1_hadr01_0-rs:hadr01
Online IBM.Equivalency:db2_public_network_0
|- Online IBM.NetworkInterface:en0:hadr01
The command “db2pd –ha” can also be issued from the instance owner ID to
'- Online IBM.NetworkInterface:en0:hadr02
examine the state of the resources:
Online IBM.Equivalency:db2_private_network_0
Online IBM.Equivalency:db2_db2inst1_db2inst1_HADRDB-rg_group-equ
|- Online IBM.PeerNode:hadr01:hadr01
'- Online IBM.PeerNode:hadr02:hadr02
Online IBM.Equivalency:db2_db2inst1_hadr01_0-rg_group-equ
23
Verify the output from “db2pd –ha”:
$ db2pd -ha
DB2 HA Status
Instance Information:
Instance Name = db2inst1
Number Of Domains =1
Number Of RGs for instance =2
Domain Information:
Domain Name = hadr_domain
Cluster Version = 3.1.2.2
Cluster State = Online
Number of nodes =2
Node Information:
Node Name State
--------------------- -------------------
hadr02 Online
hadr01 Online
Resource Group Information:

Resource Group Name = db2_db2inst1_db2inst1_HADRDB-rg
Resource Group LockState = Unlocked
Resource Group OpState = Online
Resource Group Nominal OpState = Online
Number of Group Resources =1
Number of Allowed Nodes =2
Allowed Nodes
-------------
hadr01
hadr02
Member Resource Information:
Resource Name = db2_db2inst1_db2inst1_HADRDB-rs
Resource State = Online
Resource Type = HADR
HADR Primary Instance = db2inst1
HADR Secondary Instance = db2inst1
HADR DB Name = HADRDB
HADR Primary Node = hadr01
HADR Secondary Node = hadr02
Resource Group Name = db2_db2inst1_hadr01_0-rg

Resource Group LockState = Unlocked
Resource Group OpState = Online
24
Allowed Nodes
-------------
Verify the output from “db2pd –ha” (continued):

Allowed Nodes
-------------
hadr01
Member Resource Information:
Resource Name = db2_db2inst1_hadr01_0-rs
Resource State = Online
Resource Type = DB2 Member
DB2 Member Number =0
Allowed Nodes
-------------
hadr01
Network Information:
Network Name Number of Adapters
----------------------- ------------------
db2_public_network_0 2
Node Name Adapter Name

----------------------- ------------------
hadr01 en0
hadr02 en0
Network Name Number of Adapters

----------------------- ------------------
db2_private_network_0 2
Node Name Adapter Name

----------------------- ------------------
hadr01 en1
hadr02 en1
Quorum Information:
Quorum Name Quorum State
------------------------------------ --------------------
db2_Quorum_Network_9_23_2_246:15_39_6 Online
Fail Offline
Operator Offline
25
5. Setting up an automated single network HADR
topology using the db2haicu XML mode
The configuration of an automated single network HADR topology, as illustrated in

Fig.1, is described in the steps below. Similar to the previous section:
1. The steps needed to configure a single network HADR topology is the same as
illustrated in section 4.1. In this Section we focus on describing the use of
db2haicu’s XML mode to automate the topology for failovers.
2. The parameters used for the configuration described below are based on the
topology illustrated in Fig.1. You must change the parameters to match your own
specific environment.
26
A sample db2haicu XML file is illustrated in the figure below. It contains all the
information that db2haicu needs to know in order to make a DB2 HADR instance
highly available.
<DB2Cluster xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="db2ha.xsd" clusterManagerName="TSA" version="1.0">
<ClusterDomain domainName="hadr_domain">
<Quorum quorumDeviceProtocol="network" quorumDeviceName="9.23.2.246"/>
<PhysicalNetwork physicalNetworkName="db2_public_network_0"
physicalNetworkProtocol="ip">
<Interface interfaceName="en0" clusterNodeName="hadr01">
<IPAddress baseAddress="9.23.2.124" subnetMask="255.255.255.0"
networkName="db2_public_network_0"/>
</Interface>
<Interface interfaceName="en0" clusterNodeName="hadr02">
<IPAddress baseAddress="9.23.2.198" subnetMask="255.255.255.0"
networkName="db2_public_network_0"/>
</Interface>
</PhysicalNetwork>
<ClusterNode clusterNodeName="hadr01"/>
<ClusterNode clusterNodeName="hadr02"/>
</ClusterDomain>
<FailoverPolicy>
<HADRFailover></HADRFailover>
</FailoverPolicy>
<DB2PartitionSet>
<DB2Partition dbpartitionnum="0" instanceName="db2inst1">
</DB2Partition>
</DB2PartitionSet>
<HADRDBSet>
<HADRDB databaseName="HADRDB" localInstance="db2inst1"
remoteInstance="db2inst1" localHost="hadr02" remoteHost="hadr01" />
</HADRDBSet>
</DB2Cluster>
27
The existing values in the preceding file can be replaced to reflect your own
configuration and environment. Below is a brief description of what the different
elements shown in the preceding XML file represent:
 The <ClusterDomain> element covers all cluster-wide information. This

includes: quorum information, cluster host information and cluster domain
name.
 The <PhysicalNetwork> sub-element of the ClusterDomain element includes all
network information. This includes the name of the network and the network
interface cards contained in it. We define our single public network using this
element.
 The <DB2PartitionSet> element covers the DB2 instance information. This
includes the current DB2 instance name and the DB2 partition number.
 The <HADRDBSet> covers the HADR database information. This includes the
primary host name, standby host name, primary instance name, standby
instance name and the virtual IP address associated with the database.
To configure the HADR system with db2haicu XML mode:

1) Log on to the standby instance.
2) Issue the following command:

db2haicu –f <path to XML file>
At this point, the XML file will be used to configure the standby instance. If an invalid
input is encountered during the process, db2haicu will exit with a non-zero error
code.
3) Log on to the primary instance.
4) Issue the following command again:

db2haicu –f <path to XML file>
At this point, the XML file will be used to configure the primary instance. If an invalid
input is encountered during the process, db2haicu will exit with a non-zero error
code.
The db2haicu output on the primary and the standby instances is illustrated below.
28
Sample output from running db2haicu in XML mode on standby
instance
$ db2haicu -f setup.xml
You can find detailed diagnostic information in the DB2 server diagnostic log file called db2diag.log. Also, you can
use the utility called db2pd to query the status of the cluster domains you create.
For more information about configuring your clustered environment using db2haicu, see the topic called 'DB2 High
Availability Instance Configuration Utility (db2haicu)' in the DB2 Information Center.
db2haicu is collecting information on your current setup. This step may take some time as db2haicu will need to
activate all databases for the instance to discover all paths ...
Creating domain 'hadr_domain' in the cluster ...
Creating domain 'hadr_domain' in the cluster was successful.
successful.
successful.
HADR database 'HADRDB' has been determined to be valid for high availability. However, the database cannot be
added to the cluster from this node because db2haicu detected this node is the standby for HADR database
'HADRDB'. Run db2haicu on the primary for HADR database 'HADRDB' to configure the database for automated
failover.
29
Sample output from running db2haicu in XML mode on the primary
instance
$ db2haicu -f setup.xml
db2haicu determined the current DB2 database manager instance is 'db2inst1'. The cluster configuration that follows
will apply to this instance.
Network adapter 'en0' on node 'hadr01' is already defined in network 'db2_public_network_0' and cannot be added to
another network until it is removed from its current network.
Network adapter 'en0' on node 'hadr02' is already defined in network 'db2_public_network_0' and cannot be added to
another network until it is removed from its current network.
Adding HADR database 'HADRDB' to the domain ...
Adding HADR database 'HADRDB' to the domain was successful.
Note: The messages regarding the networks (highlighted in blue above)

encountered on the primary machine can be safely ignored. These messages appear
because we have already defined the public network when running the db2haicu
command on the standby host.
30
The HADR configuration is completed right after db2haicu runs the XML file on the
primary instance. Issue the “lssam” command as root to see the resources created
during this process:

31
6. Post Configuration Testing
Once the db2haicu tool is run on both the standby and primary instances, the setup
is complete, and we can take our automated HADR environment for a test run.
Issue the “lssam” command, and observe the output displayed to the screen. You
will see something similar to the figure below:

Below is a brief description of the resources illustrated in the preceding figure and
what they represent:
1) Primary DB2 instance resource group:

db2_db2inst1_hadr01_0-rg
Member Resources:
db2_db2inst1_hadr01_0-rs (primary DB2 instance)
2) Standby DB2 instance resource group:

db2_db2inst1_hadr02_0-rg
Member Resources:
db2_db2inst1_hadr02_0-rs (standby DB2 instance)
32
3) HADR database resource group:
db2_db2inst1_db2inst1_HADRDB-rg
Member Resources:
db2_db2inst1_db2inst1_HADRDB-rs (HADR DB)
In the case of a single network HADR configuration setup, the following

equivalencies are created by db2haicu:
db2_public_network_0
db2_db2inst1_db2inst1_HADRDB-rg_group-equ
db2_db2inst1_hadr01_0-rg_group-equ
db2_db2inst1_hadr02_0-rg_group-equ
In the following steps, we will go through simulating various failure scenarios, and
how the preceding system configuration will react to such failures.
Before continuing with this section, you must note some key points:
1. The resources created by db2haicu during the configuration can be in one of the
following states:
Online: The resource has been started and is functioning normally.

Offline: The resource has been successfully stopped
Failed Offline: The resource has malfunctioned.
Note: There are two member resources for the HADR database resource group. The
“Online” resource refers to the primary HADR database resource and the “Offline”
resource refers to the standby HADR database resource. It is expected for these
resources to be in these respective states when HADR is functioning normally.
2. The term “peer” state refers to a state between the primary and standby
databases, when HADR replication is synchronized and the standby database is
capable of gracefully taking over the primary role.
3. The term “reintegration” refers to the process during which a former (old)
primary HADR database is reintegrated into the HADR pair as the new standby. This
happens in the case where the old primary database server encountered a failure
which caused a cluster-initiated takeover to take place. Once the old primary
server recovers from the failure, the old primary HADR database is reintegrated into
the HADR pair as the new standby.
33
Fig. 2. Resource groups created for a single network HADR topology
34
6.1 The “Power off” test
This test will simulate two failure scenarios: the failure of the standby host, and the
failure of the primary host.
A. Standby node failure:

Follow the instructions below to simulate standby host failure and understand the
system reaction.
1) Power off the standby machine (hadr02). The easiest way to do this is to simply
unplug the power supply.
2) Issue the “lssam” command to observe the state of the resources. You should see
something similar to the figure below:
Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Control=MemberInProblemState

Nominal=Online
'- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs Control=MemberInProblemState
'- Failed offline IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr02 Node=Offline
Failed offline IBM.ResourceGroup:db2_db2inst1_hadr02_0-rg Control=MemberInProblemState Nominal=Online
'- Failed offline IBM.Application:db2_db2inst1_hadr02_0-rs Control=MemberInProblemState
'- Failed offline IBM.Application:db2_db2inst1_hadr02_0-rs:hadr02 Node=Offline
'- Offline IBM.NetworkInterface:en0:hadr02 Node=Offline
'- Offline IBM.PeerNode:hadr02:hadr02 Node=Offline
Note: The “Failed Offline” state of all resources on hadr01 indicates a critical failure.
The primary host will ping and acquire quorum and continue to operate. The clients
will connect to the primary database uninterrupted.
3) Plug the standby machine back in.
35
4) As soon as the machine comes back online, the following series of events will take
place:
a. The standby DB2 instance will be started automatically.
b. The standby DB2 HADR database will be activated.
c. HADR pair will be resumed and the system will eventually reach
“peer” state after all transactions have been replicated to the standby.
After this, the resources will resume the states that they had prior to the failure.

'- Offline
'- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr02
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs
36
B. Primary Host Failure:
Follow the instructions below to simulate a primary host failure:
1) Unplug the power supply for the primary machine (hadr01).
2) The clients will not be able to connect to the database. Hence, the Cluster
Manager will initiate a failover operation for the HADR resource group.
a. The standby machine (hadr02) will ping and acquire quorum.

b. A cluster-initiated takeover operation will allow the standby database to
assume the primary role.
3) Issue the “lssam” or the “db2pd –ha” command to examine the state of the
resources. After the failover, the resources will settle down to the states illustrated
in the figure below:
Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Request=Lock Nominal=Online

'- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs Control=SuspendedPropagated
|- Failed offline IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr01 Node=Offline
'- Failed offline IBM.Application:db2_db2inst1_hadr01_0-rs Control=MemberInProblemState
'- Failed offline IBM.Application:db2_db2inst1_hadr01_0-rs:hadr01 Node=Offline
|- Offline IBM.NetworkInterface:en0:hadr01 Node=Offline
|- Offline IBM.PeerNode:hadr01:hadr01 Node=Offline
a. All resources on the old primary machine (hadr01) will assume the “Failed Offline”
state.
b. The HADR resource group will be locked.
37
Direct your attention towards the “Lock” placed on the HADR resource group after
the failover. This lock indicates that the HADR databases are no longer in “peer”
state. No further actions will be taken on this resource group in case of any more
failures.
4) Plug the old primary machine (hadr01) back in.
5) As soon as the old primary machine comes back up, we expect reintegration to
occur:
a. The old primary DB2 instance will be started automatically.
b. The old primary database will then be started as a “standby”.
c. As soon as the HADR system reaches “peer” state, the lock from the
HADR resource group will be removed.
38
6.2 Deactivating the HADR database
A. Deactivating the standby database:
1) Issue the following command on the standby database:

db2 deactivate db <database name>
The deactivate command will make the HADR databases not be in “peer” state
anymore. This will be reflected by a “lock” being placed on the HADR resource
group.
2) Run “lssam -noequ” or “db2pd –ha” to examine the system reaction. You will see
something similar to the output illustrated below:

Note: If the primary machine is to be powered off in such a state, a failover

operation will not be performed because of the lock placed on the HADR resource
group. Since HADR was not in “peer” state at the time of host failure, the standby
database is not the complete copy of the primary at this point and thus not suitable
to take over.
3) Activate the database again using the following command to recover from this
state:
db2 activate db <database name>
39
B. Deactivating the primary database:
1) Issue the following command on the primary database:
db2 deactivate db <database name>
2) The deactivation of the primary database will cause the HADR resource on the
primary host to go offline, and a lock to be placed on the HADR resource group.
3) Run the “lssam -noequ” or the “db2pd –ha” command. You will see something
similar to the output illustrated below:
Pending online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Request=Lock Nominal=Online

'- Offline IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs Control=StartInhibitedBecauseSuspended
|- Offline IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr01
4) The HADR resources on the primary and the standby machines will be offline. The
database must be activated again on primary to return the HADR resource group to
unlock and come online:
db2 activate db <database name>
40
6.3 DB2 Failure Test
This section discusses the HA system configuration reaction to killing or stopping the
DB2 daemons on either the primary or standby hosts.
A. Killing the DB2 instance:

1) Issue the db2_kill command on the primary instance to kill the DB2 daemons.
2) Run the “lssam” or the “db2pd –ha” command to examine the resources. You
should see something similar to the output illustrated below.
Pending online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Nominal=Online

'- Pending online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs
|- Pending online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr01
Pending online IBM.ResourceGroup:db2_db2inst1_hadr01_0-rg Nominal=Online
'- Pending online IBM.Application:db2_db2inst1_hadr01_0-rs
'- Pending online IBM.Application:db2_db2inst1_hadr01_0-rs:hadr01
3) The HADR resource and the DB2 resource on the primary host will be in a
“Pending Online” state.
4) Run the “lssam -top” command. The cluster manager will automatically start the
DB2 instance, and activate the HADR database. This will result in the “Pending
Online” state changing to an “Online” state.
We can expect the same system reaction to a db2_kill on the standby instance.
41
B. Failing the DB2 instance on the standby machine:
1) Log on to the standby instance and rename the db2start executable:
$ mv $HOME/sqllib/adm/db2star2 db2star2.mv
2) Issue the db2_kill command on the standby instance.
3) The standby DB2 resource will assume the “Pending Online” state. The cluster
manager will try to start the DB2 instance indefinitely, but will fail because of the
missing executable.
4) A timeout will occur, and any further start attempts on the DB2 resource will stop.
This will be indicated by the “Pending Online” state changing into a “Failed Offline”
state, and a lock being placed on the HADR resource group as illustrated in the
figure below:
Note: It may take 4-5 minutes for the DB2 resource timeout to occur.

'- Failed offline IBM.Application:db2_db2inst1_hadr02_0-rs
'- Failed offline IBM.Application:db2_db2inst1_hadr02_0-rs:hadr02
5) In order to recover from this state, rename the executable back to its original
name:
$ mv $HOME/sqllib/adm/db2star2.mv db2star2
6) Issue the following command with root authority on the standby host:
(root@hadr02)
$ resetrsrc –s “Name like ‘<Standby DB2 instance resource name>’ AND NodeNameList = {‘<standby node
name>’} IBM.Application
42
In our case, the command will be as follows:
resetrsrc –s “Name like ‘db2_db2inst1_hadr02_0-rs’ AND NodeNameList = {‘hadr02’}” IBM.Application
This command will reset the “Failed Offline” flag on the standby instance resource
and force the cluster manager to start the instance. The standby DB2 instance will
come online, and the standby database will be activated automatically. Once the
database is back in “peer” state, the lock on the HADR resource group will be
removed.
C. Failing the DB2 instance on the primary machine:

1) Log on to the primary instance and rename the db2start executable:
2) Issue the db2_kill command on the primary instance.
3) The primary HADR and DB2 instance resources will assume the “Pending Online”
state.
Pending online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Nominal=Online

'- Pending online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs
|- Pending online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr01
Pending online IBM.ResourceGroup:db2_db2inst1_hadr01_0-rg Nominal=Online
'- Pending online IBM.Application:db2_db2inst1_hadr01_0-rs
'- Pending online IBM.Application:db2_db2inst1_hadr01_0-rs:hadr01
4) The cluster manager will try to start the DB2 instance and activate the HADR
database:
a. The database activation will fail because the DB2 instance is not online, and a
failover will follow. A takeover operation will cause the standby database to assume
the primary role. After the failover, the HADR resource on the old primary host will
assume a “Failed Offline” state.
b. The cluster manager will continue to try to bring the DB2 instance resource online
on what is now the old primary machine. Eventually, a timeout will occur, and this
“Pending Online” state will change into the “Failed Offline” state.
43
|- Failed offline IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:hadr01
'- Failed offline IBM.Application:db2_db2inst1_hadr01_0-rs
'- Failed offline IBM.Application:db2_db2inst1_hadr01_0-rs:hadr01
Note: It may take 4-5 minutes for the DB2 resource timeout to occur.
4) In order to recover from this state, rename the db2start executable to its original
name:
6) We must reset the DB2 resource on the old primary machine to get rid of the
“Failed Offline” flag. This is done by issuing the following command with root
authority on the primary host:
(root@hadr01)
$ resetrsrc –s “Name like ‘<DB2 instance resource name on old primary>’ AND NodeNameList = {‘<primary
instance node name>’} IBM.Application
In our case, the command is as follows:
resetrsrc –s “Name like ‘db2_db2inst1_hadr01_0-rs’ AND NodeNameList = {‘hadr01’}” IBM.Application
It is important to specify the command exactly as above. Reintegration will occur

automatically, and the old primary database will assume the new standby role. After
the system has reached “peer” state, the lock on the HADR resource group will be
removed.
44
6.4 Manual Instance Control via db2stop and db2start
For various reasons, it may be desired to stop and start either the standby or
primary instance.
A. Issuing db2stop and db2stop force commands on the standby machine:
1) Issue the db2stop command on the standby machine. The following error will be
encountered and the instance will not be stopped:
$ db2stop
06/19/2012 10:13:23 0 0 SQL1025N The database manager was not stopped because databases are still
active.
SQL1025N The database manager was not stopped because databases are still active.
2) Now issue the db2stop force command on the standby instance. The command
will go through successfully and the instance will be stopped.
$ db2stop force
06/19/2012 10:15:03 0 0 SQL1064N DB2STOP processing was successful.
SQL1064N DB2STOP processing was successful.
A lock is expected to be placed on the HADR resource group and the standby
instance resource group. The figure below illustrates the effect of the ‘db2stop force’
command issued on the standby instance.

Pending online IBM.ResourceGroup:db2_db2inst1_hadr02_0-rg Request=Lock Nominal=Online
'- Offline IBM.Application:db2_db2inst1_hadr02_0-rs Control=StartInhibitedBecauseSuspended
'- Offline IBM.Application:db2_db2inst1_hadr02_0-rs:hadr02
3) In order to recover from this state, start the standby DB2 instance and activate
the database:
db2start; db2 activate database <database name>
45
B. Issuing db2stop and db2stop force commands on the primary machine:
1) Issue the db2stop command on the primary machine. The following error will be
encountered and the instance will not be stopped:
$ db2stop
06/19/2012 10:22:46 0 0 SQL1025N The database manager was not stopped because databases are still
active.
SQL1025N The database manager was not stopped because databases are still active.
2) Now issue the db2stop force command on the primary instance. The command
will go through successfully and the instance will be stopped.
$ db2stop force
06/19/2012 10:24:00 0 0 SQL1064N DB2STOP processing was successful.
SQL1064N DB2STOP processing was successful.
This will cause HADR replication to halt. To reflect this, we can expect a lock to be
placed on the HADR resource group and the primary instance resource group. The
figure below illustrates the effect of the ‘db2stop force’ command issued on the
primary instance:
Pending online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Request=Lock Nominal=Online

'- Offline IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs Control=StartInhibitedBecauseSuspended
Pending online IBM.ResourceGroup:db2_db2inst1_hadr01_0-rg Request=Lock Nominal=Online
'- Offline IBM.Application:db2_db2inst1_hadr01_0-rs Control=StartInhibitedBecauseSuspended
'- Offline IBM.Application:db2_db2inst1_hadr01_0-rs:hadr01
2) In order to recover from this state, start the DB2 instance and activate the
database:
db2start; db2 activate database <database name>
46
7. Maintenance
7.1 Disabling High Availability

To disable automation for a particular instance, the “db2haicu –disable” command
can be used. This command must be issued from both the standby and primary
database instances. After having disabled automation, the system will not respond
to any failures and all resource groups for the instance will be locked. Any
maintenance work can be performed in this state without worrying about cluster
manager intervention.
Disabling High Availability for the DB2 instance
$ db2haicu -disable
Are you sure you want to disable high availability (HA) for the database instance 'db2inst1'. This will lock all the
resource groups for the instance and disable the HA configuration parameter. The instance will not failover if a
system outage occurs while the instance is disabled. You will need to run db2haicu again to enable the instance for
HA. Disable HA for the instance 'db2inst1'? [1]
1. Yes
2. No
1
Disabling high availability for instance 'db2inst1' ...
Locking the resource group for HADR database 'HADRDB' ...
Locking the resource group for HADR database 'HADRDB' was successful.
Locking the resource group for DB2 database partition '0' ...
Locking the resource group for DB2 database partition '0' was successful.
Locking the resource group for DB2 database partition '0' ...
Locking the resource group for DB2 database partition '0' was successful.
Disabling high availability for instance 'db2inst1' was successful.
47
After having disabled automation for the instance, all DB2 resources will be locked:

Online IBM.ResourceGroup:db2_db2inst1_hadr01_0-rg Request=Lock Nominal=Online
'- Online IBM.Application:db2_db2inst1_hadr01_0-rs Control=SuspendedPropagated
Online IBM.ResourceGroup:db2_db2inst1_hadr02_0-rg Request=Lock Nominal=Online
'- Online IBM.Application:db2_db2inst1_hadr02_0-rs Control=SuspendedPropagated
In order to re-enable automation for the instance, the “db2haicu” command must
be issued from both the standby and primary database instances. At the prompt,
choose the option to re-enable high availability and pick 'TSA' as a cluster manager.
After having done this, the locks will be removed from the resources and automation
will be re-enabled.
48
Enabling High Availability for an HA DB2 instance
$ db2haicu
db2haicu has detected that high availability has been disabled for the instance 'db2inst1'. Do you want to
enable high availability for the instance 'db2inst1'? [1]
1. Yes
2. No
1
1.TSA
2.Vendor
1
Enabling high availability for instance 'db2inst1' ...
Enabling high availability for instance 'db2inst1' was successful.
49
7.2 Manual Takeover
There might be situations when a DBA wants to perform a manual takeover to
switch the HADR database roles.
To do this, log on to the standby machine and type in the following command to
perform a manual takeover.
db2 takeover hadr on db <database name>
Once the takeover has been completed successfully, the “lssam” command output
will reflect the changes.

50
7.3 db2haicu Maintenance mode
When a system is already configured for High Availability, db2haicu runs in
maintenance mode. Typing db2haicu on the primary or standby will produce the
menu illustrated below. This menu can be used to carry out various maintenance
tasks and change any Cluster Manager-specific, DB2-specific or network-specific
values configured during the initial setup.
db2haicu Maintenance mode
$ db2haicu
You can find detailed diagnostic information in the DB2 server diagnostic log file called db2diag.log. Also, you
can use the utility called db2pd to query the status of the cluster domains you create.
information, see the topic 'Creating a cluster domain with db2haicu' in the DB2 Information Center. db2haicu is
searching the current machine for an existing active cluster domain ...
Select an administrative task by number from the list below:

1. Add or remove cluster nodes.
2. Add or remove a network interface.
3. Add or remove HADR databases.
4. Add or remove an IP address.
5. Move DB2 database partitions and HADR databases for scheduled maintenance.
6. Create a new quorum device for the domain.
7. Destroy the domain.
8. Exit.
Enter your selection:
51
An example of using option 5)
1. Type "5" and press Enter
2. The following message will be displayed on the screen:
Do you want to review the status of each cluster node in the domain before you begin? [1]
1. Yes
2. No
1
Domain Name: hadr_domain
Node Name: hadr02 --- State: Online
Node Name: hadr01 --- State: Online
Enter the name of the node away from which DB2 partitions and HADR primary roles should be moved:
3. Enter the Primary machine name:
4. Press "1" to proceed to the next step:
Enter the name of the node away from which DB2 partitions and HADR primary roles should be moved:
hadr01
Cluster node 'hadr01' hosts the following resources associated with the database manager instance 'db2inst1':
HADR Database: HADRDB
All of these cluster resource groups will be moved away from the cluster node 'hadr01'. This will take their database
partitions offline for the duration of the move, or cause an HADR role switch for HADR databases. Clients will
experience an outage from this process. Are you sure you want to continue? [1]
1. Yes
2. No
1
Submitting move request for resource group 'db2_db2inst1_db2inst1_HADRDB-rg' ...
The move request for resource group 'db2_db2inst1_db2inst1_HADRDB-rg' was submitted successfully.
Do you want to make any other changes to the cluster configuration? [1]
1. Yes
2. No
2
52
Once the move request has completed successfully, the “lssam” command output
will reflect the changes.

53
8. Multiple Standby HADR in DB2 Version 10.1
The high availability disaster recover (HADR) feature supports multiple standby
databases. When you deploy the HADR feature in multiple standby mode, you can
have up to three standby databases in your setup. One of these databases is
designated as the principal HADR standby; the others are designated as auxiliary
HADR standbys. Both types of HADR standbys are synchronized with the HADR
primary database through a direct TCP/IP connection, both types support reads on
standby, and you can configure both types for time-delayed log replay. In addition,
you can issue a forced or non-forced takeover on any standby. However, there are a
couple of important distinctions between the principal and auxiliary standbys:
 IBM® Tivoli® System Automation for Multiplatforms (SA MP) automated

failover is supported only for the principal standby. You must issue a
takeover manually on one of the auxiliary standbys to make one of them the
primary.
 Both the ‘SYNC’ and ‘NEARSYNC’ synchronization modes are supported on
the principal standby, but the auxiliary standbys can only be in SUPERASYNC
mode.
For more information on this topic, please refer to:

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.a
dmin.ha.doc/doc/c0059994.html
8.1 Setup for Multiple Standby HADR

The setup for a multiple standby HADR configuration is similar to that of a single
standby HADR configuration (covered in Section 4.1.2).
1. Update the database’s HADR db cfg parameters on each machine
db cfg on Primary Machine:
db2 update db cfg for HADRDB using HADR_LOCAL_HOST <Primary>

db2 update db cfg for HADRDB using HADR_LOCAL_SVC <66666>
db2 update db cfg for HADRDB using HADR_REMOTE_HOST <Principal Standby>
db2 update db cfg for HADRDB using HADR_REMOTE_SVC <66656>
db2 update db cfg for HADRDB using HADR_REMOTE_INST <db2inst1>
db2 update db cfg for HADRDB using HADR_SYNCMODE <SYNC>
db2 update db cfg for HADRDB using HADR_PEER_WINDOW <300>
54
db cfg on Principal Standby:
db2 update db cfg for HADRDB using HADR_LOCAL_HOST <Principal Standby>

db2 update db cfg for HADRDB using HADR_REMOTE_HOST <Primary>
db2 update db cfg for HADRDB using HADR_SYNCMODE <SYNC>
db cfg on Auxiliary Standby(s)
db2 update db cfg for HADRDB using HADR_LOCAL_HOST <Auxiliary Standby>

db2 update db cfg for HADRDB using HADR_REMOTE_HOST <Primary>
Primary HADR_TARGET_LIST db cfg setting:
db2 update db cfg for HADRDB using HADR_TARGET_LIST "<Principal Standby>:<66656>|<Auxiliary

Standby>:<66646>"
Principal Standby HADR_TARGET_LIST db cfg setting:
db2 update db cfg for HADRDB using HADR_TARGET_LIST "<Primary>:<66666>|<Auxiliary

Standby>:<66646>"
Auxiliary Standby(s) HADR_TARGET_LIST db cfg setting:
db2 update db cfg for HADRDB using HADR_TARGET_LIST "<Primary>:<66666>|<Principal

Standby>:<66656>"
2. Startup Multiple Standby HADR

Start the Principal and Auxiliary Standby(s) in the same way as you would in a single
Standby HADR configuration:
db2 start hadr on db <database name> as standby
Start the Primary in the same way as you would in a single Standby configuration:
db2 start hadr on db <database name> as primary
55
8.2 Setting up an automated Multiple Standby HADR topology
with db2haicu
Cluster manager automation is only supported between the primary HADR database
and the principal standby HADR database hosts. Therefore, the db2haicu setup
procedure is the same as in the single standby HADR configuration for both the
interactive and XML modes. Similarly to Sections 4.2 and 5 of this whitepaper, the
db2haicu command must first be run to completion on the principal HADR standby
host and then on the primary HADR host. Once the db2haicu command has been run
on both hosts and automation is in place, the HADR database will be able to
automatically failover to the principal standby database host in the event of a failure
to the primary HADR host.
56
9. Troubleshooting
9.1 Unsuccessful Failover

In the case that a critical failure occurs on the primary machine, a failover action is
initiated on the HADR resource group, and as a result all HADR resources are moved
to the standby machine.
If such a failover operation is unsuccessful, it will be reflected by the fact that all
HADR resources residing on both the primary and the standby machines are in a
“Failed Offline” state.
This can be due to the following reasons:

1) The HADR_PEER_WINDOW database configuration parameter is not set to a
sufficiently large value.
When moving the HADR resources during a failure, the Cluster Manager issues the
following command on the standby database:
db2 takeover hadr on db <database name> by force peer window only
The peer window value is the amount of time within which a takeover must be done
on the standby database starting from the time when the primary database failed.
If a takeover is not done within this “window”, the aforementioned takeover
command will fail resulting in the standby database not being able to assume the
primary HADR role. Recall from Section 4.1.2, that a value of 300 seconds is
recommended for the HADR_PEER_WINDOW parameter. However, if a takeover fails
on your system, you might have to update this parameter to a larger value, and try
the failure scenario again. Also, make sure that the Network Time protocol (as
stated in Section 4.1.4) is functional and the dates and times on both the standby
and the primary machines are synchronized. If peer window expiration is what
caused the takeover to fail, a message indicating this would be logged in the DB2
diagnostic log (see Section 9.3). At this point, you can issue the following command
at the standby machine and force an HADR takeover:
db2 takeover hadr on db <database name> by force
However, prior to issuing the above command, you are urged to consult this URL:
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.a
dmin.cmd.doc/doc/r0011553.html
2) The HADR resource group is locked and the databases are not in “peer” state. In
this state, if the primary host were to fail, a failover would not be initiated. This is
because at this point, the standby database cannot be trusted to be a complete copy
of the primary, and hence not fit for a takeover.
57
9.2 The “db2haicu –delete” command
The db2haicu utility can also be run with the “-delete” option. This option deletes all
resources associated to the instance in question. If no other instance is using the
domain at the time, the cluster domain is also deleted.
As a good practice, it is recommended to run db2haicu with the delete option on an

instance before it is made highly available. This makes sure that we are starting
from scratch and not building on top of leftover resources.
For example, when running db2haicu with an XML file, any invalid attribute in the file
will cause db2haicu to exit with a non-zero error code. However, before db2haicu is
run again with the corrected XML file, one can run the –delete option to make sure
that any temporary resources created during the initial run are cleaned up.
Note that running the “db2haicu –delete” command will only affect resources for the
instance from which the command is being run from. That is, it will not stop the DB2
HADR instances. However, any virtual IP addresses that were highly available are
removed and are no longer present after the “db2haicu –delete” command
completes.
9.3 The “syslog” and the DB2 server diagnostic log file
(db2diag.log)
The DB2 High Availability (HA) feature provides some diagnostics through the
db2pd utility. The ‘db2pd –ha’ option is independent of any other option specified to
db2pd.
The information contained in the db2pd output for the HA feature is retrieved from
the cluster manager. The DB2 HA feature can only communicate with the active
cluster domain on the cluster host where it is invoked. All options will output the
name of the active cluster domain to which the local cluster host belongs, as well as
the domain’s current state.
For debugging and troubleshooting purposes, the necessary data is logged in two
files: the syslog, and the DB2 server diagnostic log file (db2diag.log).
Any DB2 instance and database related errors are logged in the db2diag.log file. The
default location of this file is $HOME/sqllib/db2dump/db2diag.log, where $HOME is
the DB2 instance home directory. You can change this location with the following
command:
db2 update dbm cfg using DIAGPATH <new diagnostic log location>
58
In addition, there are 5 diagnostic levels that can be set to control the amount of
data logged to the db2diag.log. These range from 0-4, where level 0 indicates the
logging of only the most critical errors, and level 4 indicates the maximum amount
of logging possible. Diagnostic level 3 is recommended to be set on both the primary
and the standby instances. The command to change the diagnostic level of an
instance is:
db2 update dbm cfg using DIAGLEVEL <Diagnostic level number>
The messages that are generated by the TSA and RSCT subsystems are the first
source of information in troubleshooting and problem determination. On AIX, the
system logger is not configured by default. Messages are written to the error log. To
be able to obtain the debug data, it is recommended that you configure the system
logger in the file /etc/syslog.conf. Add the following line to the file:
*.debug /tmp/syslog.out rotate size 500k time 1w files 10 compress archive

/var/log
Following this, create the /tmp/syslog.out file. After you have made the necessary
changes, you must recycle the syslog daemon by running the following command:
refresh –s syslogd
59
®
© Copyright IBM Corporation 2011

IBM United States of America
Produced in the United States of America
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local
IBM representative for information on the products and services currently available in your area. Any reference to an
IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may
be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property
right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM
product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing,
to:
IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PAPER “AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement
may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes may be made periodically to
the information herein; these changes may be incorporated in subsequent versions of the paper. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time without
notice.
Any references in this document to non-IBM Web sites are provided for convenience only and do not in any manner
serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this
IBM product and use of those Web sites is at your own risk.
60
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing,
to:
IBM Director of Licensing

IBM Corporation
4205 South Miami Boulevard
Research Triangle Park, NC 27709 U.S.A.
All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and
represent goals and objectives only.
This information is for planning purposes only. The information herein is subject to change before the products
described become available.
If you are viewing this information softcopy, the photographs and color illustrations may not appear.
61
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on
their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or
common law trademarks owned by IBM at the time this information was published. Such trademarks may also be
registered or common law trademarks in other countries. A current list of IBM trademarks is available on the web at
"Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is
registered in the U.S. Patent and Trademark Office.
UNIX is a registered trademark of The Open Group in the United States and other countries.
62

Autom Ating HADR On DB2 10.1 For Linux, UNIX and Windows Failover Solution Using Tivoli System Automation For Multiplatforms

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Autom Ating HADR On DB2 10.1 For Linux, UNIX and Windows Failover Solution Using Tivoli System Automation For Multiplatforms

Hochgeladen von

Copyright:

Verfügbare Formate

Automating HADR on DB2 10.

Target Audience for this paper:

Below you will find information on knowledge requirements, as well as hardware

2.1 Knowledge Prerequisites

*Information on DB2 HADR can be found here:

**Information on TSA can be found here:

2.2 Hardware Configuration Used in Setup

2.3 Software Version used in Setup

3.1 The db2haicu utility

3.2 HADR Overview

3.3 Typical HADR topologies

topology using db2haicu Interactive mode

The configuration of an automated single network HADR topology, as illustrated in

4.1 Topology Configuration

9.23.2.124 hadr01.fullyQualifiedDomain.com hadr01

4.1.2 HADR Database Setup

2. Update the following parameters on the Primary instance ‘db2inst1’ to configure

4. On the Standby instance, restore the database HADRDB.

5. Update the following parameters on the Standby instance ‘db2inst1’ to configure

A) Note that the configuration values HADR_REMOTE_HOST and

B) Set the HADR_PEER_WINDOW configuration parameter to a large enough value

You should see something similar to the output illustrated below.

Database Member 0 -- Database HADRDB -- Standby -- Up 0 days 00:02:46 -- Date

Database Member 0 -- Database HADRDB -- Active -- Up 0 days 00:06:28 -- Date 2012-06-11-11.56.59.648102

(root@hadr01) $ preprpnode hadr01 hadr02

4.1.4 Network Time Protocol

4.1.5 Client Reroute

Automatic Client Reroute (ACR)

2. The client reroute configuration can then be validated as follows:

Primary - (db2inst1@hadr01) /home/db2inst1

$ db2 list db directory

Creating a Cluster Domain

Create a domain and continue? [1]

Enter the host name of a machine to add to the domain:

Create the domain now? [1]

You will be prompted by db2haicu to enter quorum configuration values:

Configure a quorum device for the domain called 'hadr_domain'? [1]

From the preceding prompt:

An example is illustrated below:

a) public network setup

For our purposes, we select TSA:

Retrieving high availability configuration parameter for instance 'db2inst1' ...

Automate HADR failover

Cluster Manager Selection

Retrieving high availability configuration parameter for instance 'db2inst1' ...

Virtual IP address setup

However, if making use of a virtual IP address is the preferred method of achieving

Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Nominal=Online

Resource Group Information:

Resource Group Name = db2_db2inst1_hadr01_0-rg

Resource Group Nominal OpState = Online

Node Name Adapter Name

Network Name Number of Adapters

Node Name Adapter Name

topology using the db2haicu XML mode

The configuration of an automated single network HADR topology, as illustrated in

 The <ClusterDomain> element covers all cluster-wide information. This

To configure the HADR system with db2haicu XML mode:

2) Issue the following command:

3) Log on to the primary instance.

4) Issue the following command again:

Note: The messages regarding the networks (highlighted in blue above)

Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg Nominal=Online