Information Management Technology Ecosystem

High Availability and Disaster Recovery

Information Management

© 2012 IBM Corporation

Information Management

Agenda
■ HADR: Concepts and Capabilities
■ Requirements
■ Configuration
■ Reads on Standby
■ Takeover Operation
■ Multiple-Standby Overview

2 © 2012 IBM Corporation

Information Management

HADR Concept

■ HADR is a database replication feature that provides a high availability solution for
both partial and complete site failures.
■ HADR is based on a pair (primary and standby) of databases. In case of failure, the
standby database can take over the workload
– Primary
• Handles all client connections and processes transactions
• Continuously ships transaction logs to the standby over the network
– Standby
• Kept in sync with primary by applying received transaction logs

Network Connection
tx tx
tx tx

HADR
Keeps the two
servers in sync

Primary Server Standby Server © 2012 IBM Corporation

Information Management

HADR Capabilities
■ High Availability
– Automatic Failover with Tivoli System Automation
– Automatic Client Reroute
■ Reads-on Standby
– Offloading read transactions from the primary server to standby servers
■ Multiple Standby City A Read / Write
session 1
– Local standby for high availability
– Remote standby for disaster recovery Server 1

City B Read-only
session 5
Database
Primary Read / Write
session 2

HADR
Read-only A
session 4 ns
tio
s ac
an
Tr

Transactions

Server 3

Standby Server 2
Database
HADR Standby Read--only
A session 3
Database
HADR
A

© 2012 IBM Corporation

Information Management

Benefits of HADR

■ Minimizes impact of planned and unplanned outage

–Eg: Software upgrades without interruption
■ Client applications can easily recover from disaster reducing
data loss and downtime
–No rewrite of your application
–Ultra fast and transparent failover
–Easy integration with high availability clustering software
■ Negligible impact on performance
■ Easy administration and setup
–No specialized hardware required
–Setup in only minutes with graphical wizard

© 2012 IBM Corporation

Information Management

HADR Scope

■ HADR replication takes place at database level

Server 1 Server 2

Primary Standby
TCP/IP
HADR
Database A HADR Database A

Database C
Database B

Database D
Standby
Primary
TCP/IP
Database E HADR Database E
HADR

© 2012 IBM Corporation

Information Management

What Gets Replicated?

■ Operations replicated under HADR:

– DDL and DML statements
– Buffer pool and table space operations, as well as storage-related operations
performed on automatic storage databases (ALTER DATABASE)
– Online/Offline reorganization
– Changes to metadata (system catalog information)
for stored procedure and user-defined functions (UDFs)
– Load operations with COPY YES option
■ Operations not replicated under HADR:
– Database configuration parameters
– Tables created with the NOT LOGGED INITIALLY option
– Non-logged LOB columns
– UDF libraries
– Index pages (unless LOGINDEXBUILD is enabled)

© 2012 IBM Corporation

Information Management

HADR Synchronization Modes

■ Synchronous
– Greatest protection against transaction loss
– A higher cost of transaction response time
■ Near Synchronous (default)
– Better performance than Synchronous mode
• no waiting for the log buffer to be written to disk on
standby
■ Asynchronous
– If latency of the network between the two servers is too great
■ Super Asynchronous
– Better response time during network interruptions or congestion
Primary Standby
Log shipping
HADR HADR
send buffer receive buffer
Asynchronous Near-synchronous
Log Log
Writer Writer

Super Asynchronous
Synchronous
Log Log
8 © 2012 IBM Corporation
Information Management

HADR Requirements
Server 1 Server 2
■ Both primary and standby systems must have similar
hardware and software configuration
■ Hardware
– Server: same vendor and architecture
– Memory: identical amounts of memory to support replayed buffer pool operations
– Network: a TCP/IP network between the HADR systems, connected over a high-
speed, high-capacity network
• Recommendation: an extra network to separate internal HADR traffic from
workload / client traffic
■ Software
– OS: identical version including patch level
– DB2: identical bit size (32 or 64) and version
• Supports rolling upgrades
■ Database Configuration
– Not supported in a partitioned database environment
– Primary and standby databases must have the same database name
– Table spaces must be identical on the primary and standby databases

© 2012 IBM Corporation

Information Management

HADR Configuration Parameters Explained

■ hadr_db_role (READ-ONLY)
– This parameter indicates the current role of a database
■ hadr_<local/remote>_host
– specifies the local/remote host for HADR TCP communication
■ hadr_<local/remote>_svc
– specifies the TCP service name/ port number for which the local/remote HADR
process accepts connections
■ hadr_peer_window
– Specifies the amount of time that HADR primary-standby database pair continues
to behave as though still in peer state, if the primary database loses connection
with the standby database.
■ hadr_remote_inst
– specifies the instance name of the remote server.
■ hadr_timeout
– specifies the time (in secs) that the HADR process waits before considering a
communication attempt to have failed
– Too long
• In peer state, if standby is not responding, transactions on primary can
hang for HADR_TIMEOUT period. Recommend: at least 10 seconds.
– Too short
• You get false alarm on the connection.
• Frequent disconnection and reconnection wastes resource.
• HA protection also suffer as disconnection brings primary out of peer state.
© 2012 IBM Corporation
Information Management

Basic HADR Configuration

Primary Setup Standby Setup

1. db2 backup db hadr_db to backup_dir 2. db2 restore db hadr_db from backup_dir

3. db2 update db cfg for hadr_db using 4. db2 update db cfg for hadr_db using
HADR_LOCAL_HOST host_a HADR_LOCAL_HOST host_b
HADR_REMOTE_HOST host_b HADR_REMOTE_HOST host_a
HADR_LOCAL_SVC svc_a HADR_LOCAL_SVC svc_b
HADR_REMOTE_SVC svc_b HADR_REMOTE_SVC svc_a
HADR_REMOTE_INST inst_b HADR_REMOTE_INST inst_a
HADR_TIMEOUT 120 HADR_TIMEOUT 120
HADR_SYNCMODE ASYNC HADR_SYNCMODE ASYNC

6. db2 start hadr on database hadr_db 5. db2 start hadr on database hadr_db as
as primary secondary

© 2012 IBM Corporation

Information Management

Configuring Reads on Standby (RoS)

■ Perform read-only operations on HADR standby database
– Run concurrent read-only workloads offloading reporting, DSS/BI workloads to
standby with minimal impact
– Enabled by DB2_HADR_ROS registry variable
■ During failover, DB2 seamlessly turns the read-on-standby to a primary read/write
server
■ Restrictions
– Only Uncommitted Read (UR) isolation level is supported on the standby
– Workload manager DDL statements on the primary are replayed on the standby,
but they will not be effective on the standby
– Some DB2 features and objects are not supported
• CGTTs, DGTTs, not logged initially tables,not-inlined LOBs and XML, LONG
VARCHAR, LONG GRAPHIC, STMM
Read
Server 1 Server 2 session 3
Read/Write
session 1
Read/Write
session 2

Primary Writes for session 1 Standby

Writes for session 2
Database A
Database A HADR HADR
(with RoS)
© 2012 IBM Corporation
Information Management

HADR Configuration – HADR Delayed

Replay
New in DB2 10
■ HADR_REPLAY_DELAY - New configuration parameter which will control how far
behind (in seconds) the standby will intentionally remain at all times
■ Very useful to prevent data loss due to errant transactions.
– Eg: You can delay the HADR replication by 24h, creating a safe point-of-restore for
unwanted transactions.
– Max value is 2147483647 seconds
■ Can only be set on a standby database
■ A TAKEOVER command on a standby with replay delay enabled will fail
– You must first set the hadr_replay_delay configuration parameter to 0 and then
deactivate and reactivate the standby to pick up the new value, and then issue the
TAKEOVER command
■ The delayed replay feature is supported only in SUPERASYNC mode

© 2012 IBM Corporation

Information Management

HADR Fine Tuning – a Standby Log Spooling

■ The log spooling feature allow the standby to spool log records arriving from the
primary
– This decouples log replay on the standby from receiving of the log data from the
primary
– Logs will be spooled in the standby DB’s active log path
■ Reduces impact on primary database caused by slow log replay on standby.
– Eg: When intensive operations like reorgs are replayed on the standby.
■ Set through a new DB CFG parameter: HADR_SPOOL_LIMIT
■ Can limit the amount of space allocated to the log spool by specifying the maximum
amount of disk space to use
– Value of 0 disables spooling (default)
– Value of -1 defines the spool to be unlimited (limited by file system free space)
■ Log files will be automatically deleted when they are no longer required
■ Log spooling does not cause data loss. The data shipped from the primary is still
replicated to the standby using the specified synchronization mode.
■ Takeover may take longer as the spool must be drained before takeover completes

© 2012 IBM Corporation

Information Management

SUPERASYNC or Log Spooling?

■ Superasync mode
–Eliminates back pressure on the primary
• Useful network is slow
■ Log spooling
–Allows receipt of log records regardless of log replay on the
standby
• Useful if standby has limited resources
• Can be used with any synchronization mode
■ Both features can be combined
Slow
network
and a Slow
standby

© 2012 IBM Corporation

Information Management

HADR Takeover Operation

■ Normal Takeover
– 1. Standby tells primary that it is taking over
– 2. Primary forces off all client connections and refuses new connections
– 3. Primary rolls back any open transactions and ships remaining
log, up to the end of log, to standby
– 4. Standby replays received log, up to end of the log
– 5. Primary becomes new standby, standby becomes new primary
– 7. ACR will automatically reroute client applications to new primary
TAKEOVER HADR ON DATABASE <dbname>

■ By Force
– 1. Standby sends a notice asking the primary to shut itself down
– 2. Standby does NOT wait for any acknowledgement from the primary to confirm
that it has received the takeover notification or that it has shut down (must be
within peer window)
– 3. Standby stops receiving logs from the primary, finishes replaying the logs it has
already received, and then becomes a primary.

TAKEOVER HADR ON DATABASE <dbname> BY FORCE

© 2012 IBM Corporation

Information Management

Normal Takeover Example

HADR in peer state Primary
HADR
▬ Deactivate HADR on the Standby
HADR

Upgrade the standby
Primary

Start the standby again HADR

▬ Let it catch-up with primary

Issue a normal TAKEOVER
HADR
▬ The primary and standby change roles HADR

Suspend the new standby

HADR Primary

Upgrade the new standby HADR

Reactivate the new standby

▬ Let it catch-up with primary
HADR Primary

Optionally, TAKEOVER again
HADR
▬ The primary and standby play their
original roles
HADR
Primyary

© 2012 IBM Corporation

Information Management

By Force Takeover Example

1 - Standby sends a notice asking the primary to shut itself down

2 - Standby does NOT wait for any acknowledgement from the primary to confirm that
it has received the takeover notification or that it has shut down (must be within
peer window)

3 - Standby stops receiving logs from the primary, finishes replaying the logs it has
already received, and then becomes a primary.

Note: The option “by force peer window only” only succeeds within the peer window

TAKEOVER HADR ON DATABASE

<dbname> by force

Server 1 Takeover Server 2

New Primary

Original Original
Primary Standby
© 2012 IBM Corporation
Information Management

Automatic Failover with Cluster Manager

Provides quorum between the primary and standby nodes to

prevent split-brain scenario

Supported cluster management software
▬ AIX: High Availability Cluster Multi-Processing (HACMP)
▬ Linux: Tivoli System Automation
▬ Microsoft: Microsoft Cluster Server
▬ Solaris: Sun Cluster or VERITAS Cluster Server
▬ Hewlett-Packard: Multi-Computer/ServiceGuard

For more information:

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha
.doc/doc/r0051388.html
19 © 2012 IBM Corporation
Information Management

Tivoli System Automation for Multiplatforms (TSA)

■ DB2 is integrated with Tivoli System Automation for Multiplatforms

(SA MP) for node failure detection and automatic failover
– On Windows, SA MP is bundled and integrated with DB2 installer -
Since V9.7 FP5
■ Easily set up using the db2haicu wizard
■ Supported Operating Systems for SA MP
– AIX 5.3 and 6.1
– Linux
• Red Hat RHEL 4.6 and 5.0 (32 and 64 bit)
• SUSE SLES 9 & 10 (32 and 64 bit)
– Windows 2003 and 2008 Standard / Enterprise Edition
– Microsoft Cluster Services can be used for for HADR
failover
– Solaris 10 on SPARC (64-bit)

20 © 2012 IBM Corporation

Information Management

Automatic Client Reroute (ACR)

■ Redirects client applications from primary database to standby

database immediately after a failover operation is performed
■ Transparent to the application
■ Applications can recover from a loss of communications with minimal
interruption
■ Configuration:
▬ If you set up HADR using the Set Up HADR Databases Wizard,
Automatic Client Reroute is enabled by default
▬ If you set up HADR manually, you can enable the Automatic Client
Reroute feature by executing the UPDATE ALTERNATE SERVER FOR
DATABASE command

21 © 2012 IBM Corporation

Information Management

Automatic Client Reroute (ACR)

■ Automatically reconnects to the alternate server when the database

connection fails (transparent to the application)
■ Application must be able to catch the exception SQL30108 “A
connection failed but has been re-established. …”
■ Works not only with HADR, but also with normal databases or with
DPF, SQL Replication, etc.
22 © 2012 IBM Corporation
Information Management

Configuring a clustered environment using db2haicu

■ DB2 High Availability Instance Configuration Utility (db2haicu)

■ Text based utility to configure and administer your highly
available databases in a clustered environment
■ db2haicu collects information about database instance, cluster
environment, and cluster manager by querying your system
■ More information is supplied through interactive mode or
through XML input file

23 © 2012 IBM Corporation

Information Management

Multiple Standby Overview

Primary

Support for up to two(2)

Auxiliary Auxiliary Standbys (AS)
Standby AS supports super async
mode only
super No automated takeover
async
m ode on supported
ly Always feed from the
current primary
Can be added dynamically
any sync Principal
mode Standby Auxiliary
Standby

Principal Standby (PS) equivalent to standby today

PS supports any sync mode
Can automate takeover using integrated TSA

© 2012 IBM Corporation

Information Management

Multiple Standby Considerations

■ You can have a maximum of three standby databases:

– One principal standby
– Two auxiliary standbys
■ Only the principal standby supports all the HADR synchronization
modes
– All auxiliary standbys will be in SUPERASYNC mode
■ IBM Tivoli System Automation for Multiplatforms (SA MP) support
applies only between the primary HADR database and its principal
standby
■ You must set the new hadr_target_list database configuration
parameter on all HADR databases to enable the multiple standby mode.
■ HADR_TARGET_LIST
– Specifies a list of up to three target host:port pairs that act as HADR
standby databases.
– For a primary server, it determines which hosts act as standbys for
that primary
– For a standby server, it identifies the standby hosts to be used if this
standby takes over as the new HADR primary database
© 2012 IBM Corporation
Information Management

Automatic Reconfiguration
■ Reconfiguration after HADR service is started
– Values for hadr_remote_host, hadr_remote_inst, and
hadr_remote_svc configuration parameters are automatically reset when
HADR starts if you did not correctly set them.

■ Reconfiguration during and after a takeover

– Values for the hadr_remote_host, hadr_remote_inst, and
hadr_remote_svc configuration parameters are updated automatically on
all the databases that are part of the new setup.
– Any database that is not a valid standby for the new primary is not
updated.

© 2012 IBM Corporation

Information Management

Takeover Behavior in Multiple Standby

■
Environment
Two types of takeovers as in traditional HADR
– Role Switch (non-forced takeover)
• Can be performed only when the primary is available and it switches the
role of primary and standby. Provides zero data loss guarantee
– Failover
• Can be performed when the primary is not available. It is commonly used in
primary failure cases to make the standby the new primary.

■ Both types of takeover are supported in multiple standby mode, and any of the
standby databases can take over as the primary.

If a standby is not included in the new primary's target list, it is

considered to be orphaned and cannot connect to the new primary.

■ After a takeover, DB2 auto-redirects and makes necessary configuration changes

(host/service/instance name of new primary) on the standbys that are in the new
primary's target list (and vice versa)

© 2012 IBM Corporation

Information Management

HADR Multiple Standby Example

Primary Auxiliary standby

SUPERASYNC
Host name: host1
Hostname: host3
Port: 10
Port: 41
Instance name: dbinst1
Instance name: dbinst3
SYNC

SU
Principal standby PE
RA Auxiliary standby
SY
Hostname: host2 NC Hostname: host4
Port: 40 Port: 42
Instance name: dbinst2 Instance name: dbinst4

City A City B
© 2012 IBM Corporation
Information Management

Configurations of Each Host

Configuration Host1 Host2 Host3 Host4
parameter
Hadr_target_list host2:40 | host1:10 | host1:10 | host1:10 |

host3:41 | host3:41 | host2:40 | host2:40 |

host4:42 host4:42 host4:42 host3:41

Hadr_remote_host host2 host1 host1 host1

Hadr_remote_svc 40 10 10 10

Hadr_remote_inst dbinst2 dbinst1 dbinst1 dbinst1

Hadr_local_host host1 host2 host3 host4

Hadr_local_svc 10 40 41 42

Operational sync sync superasync superasync

Hadr_syncmode
Effective N/A sync superasync superasync
Hadr_syncmode
© 2012 IBM Corporation
Information Management

Initial Setup
■ Step 1: Create a backup image
– On host1 (primary)

DB2 BACKUP DB HADR_DB to /nfs/db_backup

■ Step 2: Initialize the standbys

– On each of host2, host3, and host 4

DB2 RESTORE DB HADR_DB from /nfs/db_backup

■ Step 3: Update the configuration

– the HADR_TARGET_LIST should be set to the following on all nodes:

principalHost:Principalsvc | auxhost1:auxsvc1 | auxhost2:auxsvc2

■ The following are not required to be set in a multiple standby environment as they
will be automatically set
– hadr_remote_host
– hadr_remote_svc
– hadr_remote_inst

© 2012 IBM Corporation

Information Management

Initial Setup
■ On host1 (the primary) ■ On host3 (auxiliary standby)

DB2 "UPDATE DB CFG FOR hadr_db USING DB2 "UPDATE DB CFG FOR hadr_db USING
HADR_TARGET_LIST HADR_TARGET_LIST
host2:40|host3:41|host4:42 host1:10|host2:40|host4:42
HADR_REMOTE_HOST host2 HADR_REMOTE_HOST host1
HADR_REMOTE_SVC 40 HADR_REMOTE_SVC 10
HADR_LOCAL_HOST host1 HADR_LOCAL_HOST host3
HADR_LOCAL_SVC 10 HADR_LOCAL_SVC 41
HADR_SYNCMODE sync HADR_SYNCMODE superasync
HADR_REMOTE_INST db2inst2" HADR_REMOTE_INST db2inst1“

■ On host2 (principal standby) ■ On host4 (principal standby)

DB2 "UPDATE DB CFG FOR hadr_db USING DB2 "UPDATE DB CFG FOR hadr_db USING
HADR_TARGET_LIST HADR_TARGET_LIST
host1:10|host3:41|host4:42 host1:10|host2:40|host3:41
HADR_REMOTE_HOST host1 HADR_REMOTE_HOST host1
HADR_REMOTE_SVC 10
HADR_LOCAL_HOST host2
HADR_REMOTE_SVC 10
HADR_LOCAL_HOST host4
24h delay
HADR_LOCAL_SVC 40 HADR_LOCAL_SVC 42
HADR_SYNCMODE sync HADR_SYNCMODE superasync
HADR_REMOTE_INST db2inst1" HADR_REMOTE_INST db2inst1
HADR_REPLAY_DELAY 86400"
© 2012 IBM Corporation
Information Management

Starting HADR

■ The DBA starts the standby databases first, by issuing the following command on
each of host2, host3, and host 4

DB2 START HADR ON DB hadr_db AS STANDBY

■ Next, the DBA starts HADR on the primary database, on host1

DB2 START HADR ON DB hadr_db AS PRIMARY

© 2012 IBM Corporation

Information Management

HADR Multiple Standby Example

Primary Auxiliary standby

SUPERASYNC Hostname: host3
Host name: host1
Port: 41
Port: 10 Instance name: dbinst3
Instance name: dbinst1

SYNC

SU
Principal standby PE
RA Auxiliary standby
SY
Hostname: host2 NC Hostname: host4
Port: 42
Port: 40 Instance name: dbinst4
Instance name: dbinst2

TAKEOVER

City A City B

© 2012 IBM Corporation

Information Management

HADR – Principal Standby Takeover

Principal standby Auxiliary standby

Host name: host1 Hostname: host3
Port: 41
Port: 10 Instance name: dbinst3
Instance name: dbinst1

SYNC

SUPERASYNC

Primary Auxiliary standby

Hostname: host2 Hostname: host4
Port: 42
Port: 40 Instance name: dbinst4
Instance name: dbinst2 SUPERASYNC

City A City B

© 2012 IBM Corporation

Information Management

After Issuing Takeover on host2 (Auto

Configuration Reconfigured)
Host1 Host2 Host3 Host4
parameter
Hadr_target_list host2:40 | host1:10 | host1:10 | host1:10 |

host3:41 | host3:41 | host2:40 | host2:40 |

host4:42 host4:42 host4:42 host3:41

Hadr_remote_host host2 host1 host2 host2

Hadr_remote_svc 40 10 40 40

Hadr_remote_inst dbinst2 dbinst1 dbinst2 dbinst2

Hadr_local_host host1 host2 host3 host4

Hadr_local_svc 10 40 41 42

Operational sync sync superasync superasync

Hadr_syncmode
Effective sync N/A superasync superasync

Hadr_syncmode

© 2012 IBM Corporation

Information Management

Hosts 1 and 2 Are Down.

takeover
Primary Auxiliary standby
SUPERASYNC
Host name: host1
Hostname: host3
Port: 10
Port: 41
Instance name: dbinst1
Instance name: dbinst3
SYNC

SU
Principal standby PE
RA Auxiliary standby
SY
Hostname: host2 NC Hostname: host4
Port: 40 Port: 42
Instance name: dbinst2 Instance name: dbinst4

City A City B
© 2012 IBM Corporation
Information Management

After Issuing Takeover on Host3 (Host 1+2

Are Down)

Primary
Host name: host1 Hostname: host3
Port: 10 Port: 41
Instance name: dbinst3
Instance name: dbinst1

SUPERASYNC
Auxiliary
standby
Hostname: host2 Hostname: host4
Port: 42
Port: 40 Instance name: dbinst4
Instance name: dbinst2

City A City B
© 2012 IBM Corporation
Information Management

After Issuing Takeover on host3 (host 1+2

Configuration Are Down)Host2
Host1 Host3 Host4
parameter
Hadr_target_list host2:40 | host1:10 | host1:10 | host1:10 |

host3:41 | host3:41 | host2:40 | host2:40 |

host4:42 host4:42 host4:42 host3:41

Hadr_remote_host host2 host1 Host4 host3

Hadr_remote_svc 40 10 42 41

Hadr_remote_inst dbinst2 dbinst1 dbinst4 dbinst3

Hadr_local_host host1 host2 host3 host4

Hadr_local_svc 10 40 41 42

Operational sync sync superasync superasync

Hadr_syncmode
Effective N/A sync n/a superasync

Hadr_syncmode
© 2012 IBM Corporation
Information Management

Host 2 is Back Online

Primary
Host name: host1
Hostname: host3
Port: 10
Port: 41
Instance name: dbinst1
Instance name: dbinst3

SUPERASYNC
Y NC
R AS
UPE
S
Principal standby Auxiliary
Hostname: host2 standby Hostname: host4
Port: 40 Port: 42
Instance name: dbinst2 Instance name: dbinst4

City A City B
© 2012 IBM Corporation
Information Management

Host 2 is Back Online

Configuration Host1 Host2 Host3 Host4
parameter
Hadr_target_list host2:40 | host1:10 | host1:10 | host1:10 |

host3:41 | host3:41 | host2:40 | host2:40 |

host4:42 host4:42 host4:42 host3:41

Hadr_remote_host host2 host3 host2 host3

Hadr_remote_svc 40 41 40 41

Hadr_remote_inst dbinst2 dbinst3 dbinst2 dbinst3

Hadr_local_host host1 host2 host3 host4

Hadr_local_svc 10 40 41 42

Operational sync sync superasync superasync

Hadr_syncmode
Effective N/A superasync n/a superasync

Hadr_syncmode
© 2012 IBM Corporation
Information Management

Host 1 is Back Online

Auxiliary standby
SUPERA Primary
S YNC
Host name: host1
Hostname: host3
Port: 10
Port: 41
Instance name: dbinst1
Instance name: dbinst3

SUPERASYNC
Y NC
R AS
UPE
S
Principal standby Auxiliary
Hostname: host2 Standby Hostname: host4
Port: 40 Port: 42
Instance name: dbinst2 Instance name: dbinst4

City A City B
© 2012 IBM Corporation
Information Management

Host 1 is Back Online

Configuration Host1 Host2 Host3 Host4
parameter
Hadr_target_list host2:40 | host1:10 | host1:10 | host1:10 |

host3:41 | host3:41 | host2:40 | host2:40 |

host4:42 host4:42 host4:42 host3:41

Hadr_remote_host host3 host3 host2 host3

Hadr_remote_svc 41 41 40 41

Hadr_remote_inst dbinst3 dbinst3 dbinst2 dbinst3

Hadr_local_host host1 host2 host3 host4

Hadr_local_svc 10 40 41 42

Operational sync sync superasync superasync

Hadr_syncmode
Effective superasync superasync n/a superasync

Hadr_syncmode
© 2012 IBM Corporation
Information Management

Monitoring HADR
■ There are a number of methods to monitor the status of HADR databases:
– db2pd utility and GET SNAPSHOT FOR DATABASE command
• From the primary = information about the primary and all standbys
• From a standby = information about that standby and the primary

■ To monitor the current role of the database is indicated by the database

configuration parameter hadr_db_role

• db2pd has been changed to display one entry for each primary-standby pair

db2pd -db HADRDB -hadr

© 2012 IBM Corporation

Information Management

Summary
■ HADR solution is based on a pair (primary and standby) of databases. In
case of failure, the standby database can take over the workload

■ HADR Reads-on-Standby feature runs concurrent read-only workloads

offloading reporting, DSS/BI workloads to standby with minimal impact

■ DB2 10 introduces
– HADR Multiple-Standby improves your ability to protect your data while
still keeping it highly available.
– HADR log spooling allows the standby to spool log records arriving from
the primary
• This decouples log replay on the standby from receiving of the log data
from the primary
– HADR Delayed Replay can allow a standby database to intentionally
remain far behind the primary at all times
• Very useful to prevent data loss due to errant transactions

© 2012 IBM Corporation

Information Management Technology Ecosystem

Questions?

E-mail: [email protected]
Subject: “DB2 10 Bootcamp”

Information Management

© 2012 IBM Corporation