Use the following procedure to set up and initialize the
primary and standby databases for DB2® high
availability disaster recovery (HADR).
About this task
HADR can be initialized through the command line processor
(CLP), the Set Up High Availability Disaster Recovery (HADR) wizard
in the Control Center, or by calling the db2HADRStart API.
To
use the CLP to initialize HADR on your system for the first time use
the following procedure:
- 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.
- 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: - The database names for the primary and standby databases must
be the same.
- 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.
- 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.
- The following RESTORE DATABASE command options
should be avoided when setting up the standby database: TABLESPACE, INTO, REDIRECT,
and WITHOUT ROLLING FORWARD.
- 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.
- 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.
- 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.
- 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.