Hadr db2express

June 08
Information Management software

High Availability and Disaster
Recovery
Creating Robust and Reliable Data Server
Clusters with IBM® DB2® Express-C 9.5

Ian Hakes
IBM Software Group

DB2 Express-C – High Availability and Disaster Recovery
Page 2

CONTENTS

1. Executive Summary

1. Executive summary

2

2. DB2 Express-C 9.5: 12 Month
License and Subscription

2

3. HADR benefits

3

4. HADR synchronization 3
5. HADR client routing

5

6. Requirements

6

7. Basic HADR setup

7

8. HADR recovery

11

9. Conclusion

12

10. Terminology

13

11 References and Resources

15

The goal of a High Availability and Disaster Recovery
(HADR) solution is to provide a means to shift data
processing and retrieval to a standby system in the
event of a primary system failure.
The recently announced DB2 Express-C 9.5: 12 Month
License and Subscription offering gives companies and
organizations with top flight database requirements the
ability to run a high availability infrastructure at a very
attractive price point.
IBM DB2 products are known for their reliability and their
extensive administration and application development
toolsets, and the inclusion of a high availability licensing
option makes DB2 Express-C an even more attractive
choice for your database software needs.

2. DB2 Express-C 9.5: 12 Month License and
Subscription
IBM announced that the no-charge DB2 Express-C
database will have an available support license
offering, aimed at lower and mid-market database
segments. This new DB2 Express-C 9.5 offering includes
a license for the DB2 High Availability (HA) code,
offering customers the ability to create a best of breed
database HADR infrastructure within their own
organizations for minimal database software costs.
The HADR application code included in this latest
offering of DB2 Express-C 9.5 seamlessly manages the
replication of logged databases for local or remote
systems. Database logs from the HADR primary system
are sent via TCP/IP network connection to the HADR
standby system where they are applied to the replica
database. This standby database is then able to take
over data transaction and processing if the primary

Page 3

system is offline, because of system upgrades,
hardware failure, or in the event of a disaster striking
the primary data center.

3. HADR Benefits
Why choose to set up an HADR solution for your
organization?
The benefits of providing your customer base with
uninterrupted data access are clear: more uptime
means more bottom line results. There are no worries
about being called to account for lost revenue or
customers due to system instability or downtime.
A full DB2-supported HADR solution gives you:
• Lightning fast failover capability, with complete
transparency for customers and client
applications
• Full transaction atomicity to prevent data loss
• The ability to upgrade systems or applications
without visible service interruption
• Remote system failover, providing full recovery
from local disaster striking the data center
• The ability to run 1 to 1, n to 1, or 1 to n scenarios
for primary to standby databases on different
systems, since HADR replication occurs at the
database level, rather than the DB2 instance
level
• Easy management with DB2 graphical tools
• All of this with negligible impact on overall system
performance over a standard database

4. HADR Synchronization
Synchronization of DB2 database logs is essential to
maintaining the HADR infrastructure between the
primary and standby systems. DB2 Express-C offers an
HADR administrator several choices for balancing
performance and reliability.

Page 4

The first option is a full Synchronous mode. In this
scenario, log writes on the primary system are held until
the standby system sends an acknowledgment that the
same log page has been written to the standby
database. The benefit here is that there is no possible
data loss between the systems, but this comes at the
cost of performance on the primary, because the
primary logging is held up until the confirmation
message is returned.
The second choice, and the default choice for DB2
HADR, is the Near Synchronous mode. In Near
Synchronous mode, the primary system again sends the
log page to the standby system, and holds the primary
log write, but in this mode, the acknowledgement
needed for the primary log write is sent back as soon as
the standby system has received the log. The standby
log writer then proceeds to add the information to the
standby database. While this does create the remote
possibility of data loss if the standby and primary both
fail simultaneously, this mode is the best compromise of
speed and reliability for the HADR infrastructure.
The final option is an Asynchronous mode, where the
primary log writes are written to the primary disk and
then sent out to the standby system for the standby log
replication. Obviously, any failure of the primary,
standby, or the connecting network would cause the
loss of the log data; then any failure to the primary
system would mean actual data loss after an HADR
failover.
The following figure outlines the three possible modes in
relation to their position in a successful database
transaction.

Page 5

Figure 1: HADR Synchronization Modes

5. HADR Client Routing
Client application connections are the heart of any
database processing system. In an HADR infrastructure,
DB2 utilizes automated client routing (ACR) settings to
properly manage client requests to the database. The
ACR is aware of which system holds the primary
database in the HADR infrastructure and will direct all
incoming client requests there.
The connection information (hostname and service
port) for the standby database is set by the HADR
administrator on the primary system. This information is
transferred to the client when a connection is made to
the primary database.
In the event of a primary database failure, the client
application will receive a connection failure message
and will then attempt to connect to the standby system
using the stored ACR information. Once the standby

Page 6

database has taken over as the new primary through
the HADR failover process, it will then accept the client
connection and the application can continue
uninterrupted.

Figure 2: HADR Automatic Client Routing

6. Requirements
To fully enable a DB2 HADR solution, both the primary
and standby systems must have:
• A reliable TCP/IP network connection
• A licensed copy of the DB2 Express-C 9.5: 12
Month License and Subscription offering to
provide the HA licensing
• The operating system and its level must be the
same (either all Windows® or all Linux®, with the
same patch level, and, on Linux, the same kernel
level)
• The DB2 application version (e.g. DB2 9.5) and
bit-level (e.g. 32 or 64 bit) must be the same
• The DB2 databases must have the same
database name on each system
• The DB2 database table spaces much be
identical in terms of table space type and size,
and the container path, size and file type must
be the same
• The DB2 buffer pool sizes should be the same

Page 7

•

The space allotted for database log files should
be the same

Bear these requirements in mind when planning to
implement an HADR solution.

7. Basic HADR Setup
In DB2, a graphical setup wizard provides the HADR
administrator an efficient and straightforward means of
creating and managing an entire HADR infrastructure
from scratch.
A complete step-by-step guide to installing the entire
HADR infrastructure is beyond the scope of this
document, but the simplified setup is as follows.
On the primary system, select the existing database to
be replicated and open the High Availability and
Disaster Recovery set up wizard:

Figure 3: Launch HADR Set Up Wizard

Page 8

After this, confirm the primary database settings, setting
up archival logging (if required), and take a database
backup. This backup will be used to create the new
standby database.
The next step is to identify the standby system and the
specific instance where the standby database will
reside:

Figure 4: HADR Standby configuration wizard

DB2 must be installed and running on the standby
system, and an instance must already exist (this is
typically part of a normal DB2 installation). The DB2
database discovery feature can be used here to
retrieve the settings for the standby DB2 server.
After the standby system and instance have been set,
the HADR wizard will create the standby database. The
recommended method is to use a recent backup of
the primary database:

Figure 5: HADR Standby initialization options

There is also an option to copy over any DB2 database
objects that are not normally part of a database
backup, so that the standby database has all the DB2

Page 9

objects as the primary database and any potential
HADR takeover will go smoothly.
The HADR wizard then configures the network
communication parameters, including the HADR ports,
and initializes the automatic client routing (ACR):

Figure 6: ACR configuration options

After the ACR configuration, the HADR Wizard asks for
the database synchronization mode, using one of 3
choices:

Figure 7: HADR Synchronization options

The final step commits all the changes and starts the
HADR on the databases.

Page 10

While executing all the HADR setup tasks, DB2
announces the status of each task with this dialog:

Figure 8: A successful HADR setup completion dialog

The HADR infrastructure is also managed from inside the
DB2 Control Center, providing a graphical view of the
HADR system status:

Figure 9: HADR management status

Page 11

This interface also provides the means to execute HADR
takeover tasks:

This is a simplified version of the entire HADR Wizard
setup process, but it is instructive to see how thorough
the wizard is in creating a customized HADR
infrastructure.

8. HADR Recovery
If disaster strikes the primary data server site, or if the
primary system or database suffers failure, then the
priority of the DB2 HADR system is to execute a failover
to the standby system, and thereby maintain data
availability for client applications. The HADR failover
and recovery process is relatively straightforward:
1. The primary database experiences a failure (due
to primary system or database crash, or disaster
at the primary site).

Page 12

2. The standby system detects the communications
failure and notifies the HADR administrator that
the primary can no longer be reached.
3. After the HADR administrator confirms the
primary failure, he or she then executes a
“Takeover by Force”, thereby turning the standby
into the new primary database. (For a fully
automated failover solution, third party HA
clustering software is required to automatically
handle the process).
4. Client applications that have been set up to use
Automated Client Routing (ACR) will now access
the new primary database for data retrieval.
5. Once the former primary system has been
restored to working state, the former primary
database is restarted as the new standby
database for the HADR infrastructure. This
prevents a “split-brain” scenario where the HADR
infrastructure has two primary databases.
6. The HADR infrastructure will then use the logs from
the new primary to bring the two databases
back to a peer state.
7. If desired, once the HADR peer state has been
achieved, the HADR roles can be switched back,
restoring the HADR databases back to the
original locations.

9. Conclusion
Continuous data availability is a business necessity in
today’s aggressively competitive marketplaces.
Application outages are unacceptable: if your
customer records, inventory levels, or e-commerce
websites are unavailable due to data server downtime,
then your organization loses customers and money.
The solution is an HADR infrastructure based on the DB2
Express-C 9.5: 12 Month License and Subscription
offering, creating a fault tolerant system to ensure that

Page 13

your data is always available, always accurate, and
always delivering customer satisfaction.

10. Terminology
Active system: Another term for a primary system in an
HA infrastructure.
Cluster: A combination of at least two computer
systems that act together to appear as a single
“virtual” system to end-user applications. In DB2
Express-C 9.5 HADR scenarios, the cluster has a primary
system, and a standby system to take over in case of a
failure.
DR: disaster recovery. The methodology of having offsite systems available to take over computing
operations, and to provide a restoration base for
primary systems, in case of catastrophic failure of the
local primary systems.
Failover: The transfer of computing operations from the
primary system to the standby system.
HA: high availability. The computer systems involved
are expected to maintain the availability of data
access and processing power at all times. Typical high
availability systems have at least 99.99% uptime.
HADR: Acronym for a computing system cluster that
offers both High Availiability and Disaster Recovery.
HADR Infrastructure: A term that refers to the primary
and standby systems, along with the network
connectivity and administration to set up and manage
the HADR computer systems
Hardware redundancy: Within a physical computer, the
hardware components have backups to handle
demand if one component fails. Typical items targeted

Page 14

for hardware redundancy are hard drives (through a
RAID) and power supplies.
Heartbeat: A short communication message, delivered
over a TCP/IP connection, between two computer
systems providing an indication that the system is online
and available.
Node: A single computer that has been incorporated
into a cluster.
Primary system: The computer system (hardware,
software and network) hosting the primary database in
a cluster. In an HADR infrastructure, this system is
responsible for primary data processing, as well as
managing the HADR synchronization.
Peer state: A term to describe the situation when two
systems in an HADR infrastructure have identical
information available for processing; in the event of a
failure, no data loss occurs during failover.
Secondary system: Another term for a standby system
in an HADR infrastructure.
Standby system: The counterpart to a primary system in
an HADR infrastructure. The standby system (hardware,
software and network) is kept up to date with the
information from the primary system. In the event of a
primary system failure, the standby system can take
over the primary system role.

Page 15

11. References and Resources
For further information on the DB2 Express-C 9.5: 12
License and Subscription offering or on IBM DB2 High
Availability and Disaster Recovery concepts and
background, visit any of these online resources:
IBM DB2 Express-C website:
• http://www.ibm.com/db2/express/
High Availability and Scalability Guide for DB2 on Linux,
UNIX and Windows Redbook:
• http://www.redbooks.ibm.com/
IBM DB2 Data Recovery and High Availability Guide
and Reference:
• ftp://ftp.software.ibm.com/ps/products/db2/info
/vr9/pdf/letter/en_US/db2hae90.pdf
IBM DB2 Information Center:
• http://publib.boulder.ibm.com/infocenter/db2lu
w/v9/

© Copyright IBM Corporation, 2007, 2008
IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada
All Rights Reserved.
Neither this documentation nor any part of it may be copied
or reproduced in any form or by any means or translated into
another language, without the prior consent of the IBM
Corporation.
DB2, DB2 Universal Database, IBM, and the IBM logo are
trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries or
both.
Linux is a registered trademark of Linus Torvalds in the United
States, other countries, or both.
Windows, is a trademark of Microsoft Corporation in the United
States, other countries, or both.
Other company, product and service names may be
trademarks or service marks of others.
The following paragraph does not apply to the United
Kingdom or any other country where such provisions are
inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied
warranties in certain transactions, therefore, this statement
may not apply to you.
Any performance data contained herein was determined in a
controlled environment. Therefore, the results obtained in
other operating environments may vary significantly. Some
measurements may have been made on development-level
systems and there is no guarantee that these measurements
will be the same on generally available systems. Furthermore,
some measurement may have been estimated through
extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific
environment.
The information contained in this document is subject to
change without any notice. IBM reserves the right to make any
such changes without obligation to notify any person of such
revision or changes. IBM makes no commitment to keep the
information contained herein up to date.
References in this publication to IBM products or services do
not imply that IBM intends to make them available in all
countries in which IBM operates.

Hadr db2express

More Related Content

What's hot (20)

Similar to Hadr db2express (20)

More from The Vision and Insight Corner (20)

Recently uploaded (20)

Hadr db2express