DB2 Version 10.1 for Linux, UNIX, and Windows

Initializing high availability disaster recovery (HADR)

Use this procedure to set up and initialize a DB2® high availability disaster recovery (HADR) primary database and one standby database.

About this task

HADR can be initialized through the command line processor (CLP), or by calling the db2HADRStart API.

Procedure

To use the CLP to initialize HADR on your system for the first time:

  1. Determine the host name, host IP address, and the service name or port number for each of the HADR databases.

    If a host has multiple network interfaces, ensure that the HADR host name or IP address maps to the intended one. You need to allocate separate HADR ports in /etc/services for each protected database. These cannot be the same as the ports allocated to the instance. The host name can only map to one IP address.

    Note: The instance names for the primary and standby databases do not have to be the same.
  2. Configure the recommended index logging and re-creation settings on the intended primary, by issuing the following command:
    "UPDATE DB CFG FOR dbname USING
         LOGINDEXBUILD   ON
         LOGARCHMETH1     method"
  3. Create the standby database by restoring a backup image or by initializing a split mirror, based on the existing database that is to be the primary.

    In the following example, the BACKUP DATABASE and RESTORE DATABASE commands are used to initialize a standby database. In this case, an NFS mounted file system is accessible at both sites.

    Issue the following command at the primary database:
    BACKUP DB dbname TO /nfs1/backups/db2/dbname
    If the database already exists on the 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 
    Issue the following command at the standby database:
    RESTORE DB dbname FROM /nfs1/backups/db2/dbname 

    The following example illustrates how to use the db2inidb utility to initialize the standby database using a split mirror of the primary database. This procedure is an alternative to the backup and restore procedure illustrated previously.

    Issue the following command at the standby database:
    DB2INIDB dbname AS STANDBY
    Note:
    1. The database names for the primary and standby databases must be the same.
    2. Do not issue the ROLLFORWARD DATABASE command on the standby database after the restore operation or split mirror initialization. The results of using a rollforward operation might differ slightly from replaying the logs using HADR on the standby database. If the databases are not identical, attempts to start the standby will fail.
    3. When creating the standby database using the RESTORE DATABASE command, ensure that the standby remains in rollforward-pending or rollforward-in-progress mode. This means that you cannot issue the ROLLFORWARD DATABASE command with either the COMPLETE option or the STOP option. An error will be returned if the START HADR command with the AS STANDBY option is attempted on the database after rollforward is stopped.
    4. The following RESTORE DATABASE command options should be avoided when setting up the standby database: TABLESPACE, INTO, REDIRECT, and WITHOUT ROLLING FORWARD.
    5. When setting up the standby database using the db2inidb utility, do not use the SNAPSHOT or MIRROR options. You can specify the RELOCATE USING option to change one or more of the following configuration attributes: instance name, log path, and database path. However, you must not change the database name or the table space container paths.
  4. On each of the databases, set the hadr_local_host, 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"
    The configuration parameters in this step, step 5, and step 6 must be set after the standby databases has been created. If they are set prior to creating the standby database, the settings on the standby database will reflect what is set on the primary database.
    Note: This is a generic HADR setup; for more advanced configuration options and settings, see the related links.
  5. Optional: Set the hadr_target_list configuration parameter on the standby and the primary:
    UPDATE DB CFG FOR dbname USING
         HADR_TARGET_LIST  principalhostname:principalservicename1
    This is an optional, but recommended, step if you are only using one standby database. If you set the hadr_target_list parameter, you can add additional standby database dynamically. You can also take advantage of the autoconfiguration behavior and specify a different synchronization mode on the standby.
  6. On each of the databases, set the hadr_remote_host, hadr_remote_svc, and hadr_remote_inst configuration parameters.
    On the primary, set the parameters to the corresponding values on the 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 the 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"

    If you have configured hadr_target_list, the values for these parameters are automatically given the proper values if they were set 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_host value to construct the resource name.

  7. Connect to the standby instance and start HADR on the standby database, as in the following example:
       START HADR ON DB dbname AS STANDBY
    Note: Usually, the standby database is started first. If you start the primary database first, this startup procedure will fail if the standby database is not started within the time period specified by the hadr_timeout database configuration parameter.
    After the standby starts, it enters local catchup state in which locally available log files are read and replayed. After it has replayed all local logs, it enters remote catchup pending state.
  8. Connect to the primary instance and start HADR on the primary database, as in the following example:
       START HADR ON DB dbname AS PRIMARY
  9. Use a monitoring interface (the MON_GET_HADR table function or the db2pd command with the -hadr option) to verify that the HADR pair enters the expected state. After the primary starts, the standby enters remote catchup state in which receives log pages from the primary and replays them. After it has replayed all log files that are on the disk of the primary database machine, both databases enter peer state (unless you have chosen SUPERASYNC as the synchronization mode).
1