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