14.12 DB2 HADR High Availability Disaster Recovery

Log shipping is a method where transaction logs are automatically copied from a primary
database server to a standby database server.

The TAKEOVER HADR command, which you can issue on the standby database only, changes
the standby database to a primary database. When you do not specify the BY FORCE option, the
primary and standby databases switch roles. When you specify the BY FORCE option, the standby
database unilaterally (without changing the primary to standby) switches to become the primary
database. In this case, the standby database attempts to stop transaction processing on the old
primary database. However, there is no guarantee that transaction processing will stop. Use the
BY FORCE option to takeover with extreme caution. Ensure that the current primary has
definitely failed, or shut it down, prior to issuing the TAKEOVER HADR command with the BY
FORCE option. Failure to do so may result in both the old primary and new primary databases
becoming active. Existing applications may continue to process transactions on the old primary,
while new applications may access the new primary. This phenomenon is sometimes known as
the “split brain” syndrome. This is obviously undesirable.

14.12.2.5 Setting Up and Initializing HADR

To initialize HADR for the first time, you need to perform the five steps:

1. Identify the primary and the standby servers. Determine the host name, host IP address,
    and the service name or port number for each of the HADR databases.
2. Create the standby database by cloning the primary database.
    There are two options to clone the primary database.
    One option is to take a backup of the primary database, and restore it on the standby
    server. This option uses the standard backup and restore method.
    The other option to clone the primary database is by split mirroring. Make a split
    mirror of the primary database and initialize it on the standby server.

In this example, the backup/restore method is used.
First, take a backup of the primary database, TEST1, on server1:
Next, move the backup image to the standby server and restore it.
Note that strict symmetry of table space and container configuration is required on
the standby database. The name, path, and size of the containers must match the primary
database. The names of the databases must be the same. If any of the configurations
do not match, HADR may fail to replicate the data to the standby database.
Therefore, before restoring the database, make sure the standby server has the same
architectural set up as the primary server.
We must restore the backup image to the same location as it is on the primary server.
The database must remain in this state in order to start HADR as a standby database properly.

3. Set the following HADR configuration parameters on both the primary and standby databases.
? HADR_LOCAL_HOST
? HADR_LOCAL_SVC
? HADR_REMOTE_HOST
? HADR_REMOTE_SVC
? HADR_REMOTE_INST
? HADR_SYNCMODE
? LOGINDEXBUILD

The default value for HADR_SYNCMODE, NEARSYNC, will be used.

issue the following commands to configure the parameters on the standby server:
UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

On the primary database server, configure the same set of parameters as shown below:
UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

4. Start HADR on the standby database using the START HADR command:
START HADR ON DB test1 AS STANDBY

It is recommended that you start the standby database before starting the primary
database. If you start the primary database first, the startup procedure will fail if the
standby database is not started within the time period specified by the
HADR_TIMEOUT database configuration parameter.

5. Start HADR on the primary database:
START HADR ON DB test1 AS PRIMARY

HADR is now started on the primary and standby databases.

When the primary server is first started, it waits for the standby server to contact it. If the
standby server does not make contact with the primary after a specific period of time, HADR
will not start. This timeout period is configurable using the HADR_TIMEOUT configuration
parameter (see Table 14.9). This behavior is designed to avoid two systems accidentally starting
up as the primary at the same time.

During the HADR startup process, the databases go through the following states: local catch-up,
remote catch-up pending, remote catch-up and peer. Logs are shipped automatically from the
primary server to the standby server, and then replayed on the standby server. This is to ensure
that the standby database is up to date with the primary database.

14.12.2.6 Performing a Takeover—Switching Database Roles

To switch database roles, issue the TAKEOVER HADR command on the standby database. Note
that the command can only be issued on the standby database and only when it is in peer state.
You can get the HADR status of a database using the GET SNAPSHOT command; for example
db2 "GET SNAPSHOT FOR DATABASE ON test1"
The following command initiates a HADR database switching role operation from the standby database TEST1:
db2 "TAKEOVER HADR ON DB test1"

14.12.2.7 Performing a Takeover—Failover
The failover option itself does not switch database roles. During a failover operation, the standby
database takes over the primary database role without having the primary database switching to
standby.
If the primary database is still active and you execute a HADR failover,
you will potentially lose data, or result in having two primary databases.
This is sometimes referred to as the “split brain” syndrome.
Before issuing the TAKEOVER command, make sure the failed primary database is completely disabled.
When a database encounters internal errors, normal shutdown commands might not
completely shut it down. You might need to use operating system commands to remove
resources such as processes, shared memory, or network connections. If the primary database is
not completely disabled, the standby database will still send a message to the primary database
asking it to shutdown. However, the standby database will not wait for the confirmation to come
back from the primary database that it has successfully shut down. The standby database will
immediately switch to the role of primary database.

To perform a HADR failover, issue the TAKEOVER command with the BY FORCE option on
the standby database. Note that the command can only be issued on the standby database and
only when it is in peer state or remote catch-up pending state.
The following command initiates a HADR failover operation on database TEST1

db2 "TAKEOVER HADR ON DB test1 BY FORCE"

14.12.2.9 The Automatic Client Reroute Feature and HADR
The DB2 automatic client reroute feature can be used to make applications highly available.
When a HADR environment is enabled with the automatic client reroute feature, after a
takeover, all current and new client connections are automatically rerouted to the new primary
server, so that the applications can continue their work with minimal interruption.

14.12.2.10 Stopping HADR
If you want to stop the specified database but you still want it to maintain its role as either an HADR
primary or standby database, do not issue the STOP HADR command. If you issue the STOP HADR
command, the database will become a standard database and may require reinitialization in order to
resume operations as an HADR database. Instead, issue the DEACTIVATE DATABASE command.
For example, to stop HADR on the TEST1 database, issue the following command:

db2 "STOP HADR ON DB test1"

DB2 HADR搭建過程

相關文章