DB2 Version 10.1 for Linux, UNIX, and Windows

Initializing HADR in multiple standby mode

Initializing an HADR system in multiple standby mode is similar to single standby mode. The main difference is that you must enable multiple standby mode by setting the hadr_target_list database configuration parameter on all the databases in your setup.

About this task

This task covers how to initialize HADR in multiple standby mode. If you want to convert a single standby setup to a multiple standby setup, see Enabling multiple standby mode on a preexisting HADR setup.

Multiple standby mode requires the hadr_target_list configuration parameter to be set on all participating databases. This parameter lists the standbys in the scenario when the database becomes a primary. It is required even on a standby. Mutual inclusion is required (that is, if A has B in its target list, B must have A in its target list). This ensures that after a takeover from any standby, the new primary can always keep the old primary as its standby. The first standby that you specify in the target list is designated as the principal HADR standby database. Additional standbys are auxiliary HADR standby databases. The target list need not always include all participants. As well, there is no requirement for symmetry or reciprocity if there is more than one standby; even if you designate that database A has database B as its principal standby, database B does not have to designate A as its principal standby. Each standby specified in the target list of database A, must also have database A in its target list. Working out the target list for each database is an important step.

As a special case, multiple standby mode can be configured with only one standby. For example, you can configure two databases as primary and standby in multiple standby mode. The behavior is not same as single standby setup because multiple standby behavior such as automated configuration will be in effect and because standby targets can be added or removed dynamically.

Tip: You can perform steps 2 to 4 in a single update on each database.

Procedure

To initialize HADR in multiple standby mode:

Create your standby database or databases by using either a restored backup or split mirror. For instructions on how to do this, see Initializing a standby database or step 2 of Initializing high availability disaster recovery (HADR).
1. On the primary, issue the following command:
```
BACKUP DB dbname
```
2. If the database already exists on a standby instance, drop it first for a clean start. Files from the existing database can interfere with HADR operation. For example, left over log files can lead the standby onto a log chain not compatible with the primary. Issue the following command to drop the database:
```
DROP DB dbname
```
3. On each standby instance, issue the following command :
```
RESTORE DB dbname
```

On each of the databases, set the hadr_local_host, hadr_local_svc, hadr_local_svc, and hadr_syncmode configuration parameters:

UPDATE DB CFG FOR dbname USING
	HADR_LOCAL_HOST   hostname
	HADR_LOCAL_SVC    servicename
	HADR_SYNCMODE     syncmode

Set the hadr_target_list configuration parameter on all of the standbys and the primary:

UPDATE DB CFG FOR dbname USING
	HADR_TARGET_LIST  principalhostname:principalservicename|
	auxhostname1:auxservicename1|auxhostname2:auxservicename2

Optional: On all the databases, set the hadr_remote_host, hadr_remote_svc, and hadr_remote_inst configuration parameters.
This step is not required because these values are automatically set if you do not set them and are automatically reset if you set them incorrectly. However, explicitly setting them to the correct values makes correct values available immediately. These values are helpful for the IBM® Tivoli® System Automation for Multiplatforms (SA MP) software, which might require the hadr_remote_inst value to construct the resource name.
- On the primary, set the parameters to the corresponding values on the principal standby by issuing the following command:
```
UPDATE DB CFG FOR  dbname USING
     HADR_REMOTE_HOST   principalhostname
     HADR_REMOTE_SVC    principalservicename
     HADR_REMOTE_INST   principalinstname
```
- On each standby, set the parameters to the corresponding values on the primary by issuing the following command:
```
UPDATE DB CFG FOR  dbname USING
     HADR_REMOTE_HOST   primaryhostname
     HADR_REMOTE_SVC    primaryservicename
     HADR_REMOTE_INST   primaryinstname
```
Connect to each standby instance.
On the standby instance, issue the START HADR command with the AS STANDBY parameter:
```
START HADR ON DB dbname AS STANDBY
```
Connect to the primary instance.
On the primary instance, issue the START HADR command with the AS PRIMARY parameter:
```
START HADR ON DB dbname AS PRIMARY
```

Results

The standby databases start in local catchup state, in which locally available log files are read and replayed. After all local logs have been replayed, the databases enter remote catchup pending state. After the primary starts, the standbys enter remote catchup state, in which log pages are received from the primary and replayed. After all of the log files that are on the disk of the primary database have been replayed on the standbys, what happens depends on the type of what happens next depends on the type of synchronization mode. A principal standby in SUPERASYNC and any auxiliary standby will stay in remote catchup mode. A principal standby with a SYNC, NEARSYNC, or ASYNC mode will enter peer mode.