Initializing high availability disaster recovery (HADR)

Use the following procedure to set up and initialize the primary and standby databases for DB2® high availability disaster recovery (HADR).

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. 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 database SOCKS as 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 socks to /nfs1/backups/db2/socks

   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, leftover log files can lead the standby onto a log chain that is not compatible with the primary. Issue the following command to drop the database:

   drop db socks

   Issue the following command at the standby database:

      restore db socks from /nfs1/backups/db2/socks 

   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 above.

   Issue the following command at the standby database:

      db2inidb socks 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.
3. Set the following HADR configuration parameters on the primary and standby databases:
   • hadr_local_host
   • hadr_local_svc
   • hadr_remote_host
   • hadr_remote_svc
   • hadr_remote_inst
   These configuration parameters 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 links below.
4. Connect to the standby instance and start HADR on the standby database, as in the following example:

      START HADR ON DB SOCKS 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.
5. Connect to the primary instance and start HADR on the primary database, as in the following example:

      START HADR ON DB SOCKS AS PRIMARY

   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.