D02 Evolution of the HADR tool

Evolution of the DB2 HADR tool
Jeyabarathi(JB) Chakrapani
NASCO
Session Code: D02
April 30, 2-3 PM | Platform: DB2 LUW

Click to edit Master title style
Evaluate my session online:
www.idug.org/na2013/eval
2

Topics covered…
1. Learn what DB2 HADR tool is and how it works to provide High
Availability.
2. Learn how much the tool has evolved with different versions.
3. Understand how to set up DB2 HADR with examples.
4. Learn how to maximize HADR performance with different
options.
5. Learn how HADR can be used beyond high availability.
3

Brief introduction to HADR and how it works to
provide high availability.
4

Brief introduction to DB2 HADR
IBM first introduced HADR in version 8.2. Since then it has
become a powerful feature within DB2 to provide a true disaster
recovery solution for business critical databases.
HADR is basically a log based replication tool. DB2 writes a log file
for each database change(except for a few changes that are not
logged) and the HADR tool reads these logs from the primary
server and applies them to the standby server.
5

 Once HADR is configured and activated, the standby database
keeps in sync with the primary database.
 Incase of a server failure or even a DB2 failure at the primary
site, a take over can be issued from the standby server so that
it becomes the primary.
 Applications can then connect to the new primary server and
resume operations.
6
Brief introduction to DB2 HADR

HADR Setup
Database E
HADR
HADR
TCP/IP
Primary Standby
Database A
HADR
HADR
TCP/IP
Standby Primary
Database A
Database E

Active
logs
Archive
logs
Tables
Indexes
HADR HADR
TCP/IP
PRIMARY SERVER
Database
Directory
SECONDARY SERVER
Database
Directory
Active
logs
Archive
logs
Tables
Indexes
Backup the
primary
Restore on standby

Synchronization modes
logs
log writer
HADR
logs
HADR
Commit Succeeded
Synchronous, Near Synchronous, Asynchronous
receive()send()
commit
send receive

HADR Setup
10

HADR Setup..
11
Choose the mode for HADR sync up. There are four modes to
choose from:
 SYNC – A commit succeeds if the log data is on the disk at
both primary and standby.
 NEARSYNC – A commit succeeds if the log data is on the disk
at the primary and written to the main memory on standby.
 ASYNC – A commit succeeds if the log data is on disk at
primary and delivered to standby.
 SUPERASYNC – Commit on the primary does not wait for
acknowledgement.

HADR Setup…
12
 Configure HADR on both primary and standby using database
configuration parameters.
 Configure HADR performance enhancing registry variables.
 Start HADR on standby.
 Start HADR on primary

HADR standby considerations
 OS type and versions must match the primary server.
 DB2 version and fix pack levels must match except for a brief
period during rolling upgrade.
 Same physical layout of file system paths is required on the
standby.
 If it is not an automatic storage database, strict symmetry of the
tablespace containers is required especially in older versions. Names,
paths and size must match. If the containers don’t match, the affected
tablespaces may be left in rollforward progress state after HADR starts.
13

HADR standby considerations …
 In V9.7, the standby server has to be enabled for Read Only
mode for applications to connect to the standby server.
 OS and DB2 must be of the same bit size (32/64 bit) as
primary.
 There is no log archival done on standby.
 STMM is not active on standby until a failover and a first
connection is made.
 System clock on primary and standby should be synchronized.
 Back up operations are not supported on standby.
14

Evolution of the tool from version to version.
15

HADR features in V8.2
 HADR was first introduced in this version along with many
other new exciting features.
 Supports three types of sync up modes.
• SYNC
• NEARSYNC
• ASYNC
16

HADR features in V8.2 …
 Reads on standby database are not supported in this version.
Users cannot connect to the standby database.
 Log archives occur only on the primary server.
 Back up operations are not supported on standby.
 LOB data are not replicated on standby.
 Tables created with NOT LOGGED INITIALLY option are not
replicated.
 Recovery history file changes are not replicated. However
there are options to update it on standby when primary gets
backed up.
17

HADR features in V8.2 ..
 Database and database manager configuration changes are not
replicated.
 Stored procedure and UDF object and library files are not
replicated. The files must be created on identical paths on the
standby.
18

HADR features in V9.1..
 All the system requirements for HADR are the same in V9.1 as
of V8.2.
 The primary and standby databases can be on the same
computer. Since they can only reside on separate instances,
the path names are unique.
 V9.1 introduced auto storage databases which are fully
supported by HADR in this version including the alter database
add storage command.
 Redirected restore for tablespace containers is not supported,
however database directory and log path changes are
supported.
19

 Most restrictions are same as V8.2 including no reads on
standby.
 HADR in V9 supports replication for logged LOB data(logged
LOBs don’t exceed 1 G in size).
 Starting with V9.1, Fp 5, it is possible to tune the TCP socket
size with the use of DB2_HADR_SOSNDBUF and
DB2_HADR_SORCVBUF registry variables without affecting the
system level TCP socket size.
 STMM is not active on standby until a failover and a first
connection.
20

 Other new registry variable available with HADR on V9.1:
 DB2_HADR-PEER_WAIT_LIMIT – V9.1 fp4
21

 A new hadr-peer-window configuration parameter is available
to protect against multiple failures.
 If this value is set to a non zero value, if the primary loses standby
connection in peer state, it enters into a disconnected peer state for
the duration of the peer window. Transactions on the primary wait for
the response from standby before they are committed.
 New scripts to facilitate HADR integration with TSA cluster
manager in FP 7.
 FP 8 added a new HADR sync mode called super async.
22

 FP4 added the block non logged db configuration parameter to
prevent non logged activities. This is useful where HADR is set
up, to allow changes on the primary to be logged and
replicated to standby.
23

 Reads on standby are allowed from V9.7 FP 1 onwards.
 Read clients can connect to the standby database as long as
the standby is not in the local catch up state or in the replay
only mode.
 Read capability is supported in all four sync modes.
24

HADR features in V10
 HADR in V10 now supports multiple standby servers providing
a true HA and DR solution.
 Delayed replay option with HADR helps protect against data
corruption and application errors.
 HADR log spooling on the standby server helps prevent the
backup on primary, improving HADR performance.
 Reads on standby are allowed in all HADR states except local
catch up state and replay_only mode.
25

HADR features in V10…
Multiple standby servers:
 Up to three standby servers can be set up.
 One can be designated as the primary standby and set up to be in close
sync with the primary server. The other two can be in remote locations
with superasync mode. One of these two can be set up with delayed
replication to further protect against application errors.
 All the standbys can be used for reads.
26

Primary
Principal
Standby
Auxiliary
Standby 2
Auxiliary
Standby 1
Any sync
mode
Super Async
Super Async
Location A Location B
Multiple Standby
Multiple standby set up

HADR_REPLAY_DELAY:
 This database configuration parameter can be updated to
specify the delay duration for the changes to be applied on the
standby.
 If a data loss or corruption happens on the primary server, it
can be recovered from the standby server if the issue is known
before the changes get applied to the standby.
28

HADR Log Spooling:
 The hadr_spool_limit database configuration parameter
enables additional space to be specified for log spooling on the
standby.
 This parameter sets an upper limit on how much data is
spooled to disk if the log receive buffer fills up.
 This allows the transactions in the primary to progress without
waiting for the log replay on standby.
29

 hadr_peer_wait_limit and hadr_peer_window configurations
 Don’t apply to the auxiliary standbys in a multiple standby set up as
these will be in super async mode and are never in peer state.
 A new configuration parameter hadr_target_list is used to
specify the host and port names of all the standby servers.
 The first name specified on the target list will be the principal
standby.
 The principal standby uses the sync mode of the primary. The
other standbys use the super async mode.
 All of the standbys have their local sync mode that will be effective if
any of them becomes the primary.
30

How to set up HADR on your DB2 servers
31

How to set up HADR on your DB2 servers
Example:
 On the primary server, make sure log archiving is enabled. If
not, make the necessary updates to enable that.
 Update the following parameters.
 HADR_LOCAL_HOST primary.server.pvt
 HADR_LOCAL_SVC db2i01_ha1
 HADR_REMOTE_HOST remote.server.pvt
 HADR_REMOTE_SVC DB2_db2i01_2
 HADR_REMOTE_INST db2i01
32

How to set up HADR on your DB2 servers…
 HADR_TIME_OUT 120
 HADR_SYNC_MODE ASYNC
 LOGINDEXREBUILD ON
 Recycle the primary DB2 instance.
 Take an online or offline backup of the primary database.
 Restore the database on the standby(do not use redirect, into
or the tablespace options).
 Leave the database in rollforward pending state.
33

 Update db cfg for standby as below:
 HADR_LOCAL_HOST remote.server.pvt
 HADR_LOCAL_SVC DB2_db2i01_2
 HADR_REMOTE_HOST primary.server.pvt
 HADR_REMOTE_SVC db2i01_ha1
 HADR_REMOTE_INST db2i01
 HADR_TIMEOUT 120
 HADR_SYNCMODE ASYNC
34

 Start hadr on standby.
 Db2 start hadr on db maindb as standby
 Start hadr on primary
 Db2 start hadr on db maindb as primary
 To monitor
 Use db2pd –hadr to check.
 The diagnostic log on the standby gives information on how the catch
up is progressing and if there are any errors.
35

HADR performance tuning
36

HADR performance tuning…
Database and server configurations that can affect HADR
performance.
 Network:
 HADR replication relies on the network connectivity.
 The recommendation is to have a network bandwidth greater than the
database log generation rate.
 Synchronization modes:
 The SYNC and NEARSYNC modes have a greater chance of affecting the
primary performance than the other two modes.
37

 DB2_HADR_SOSNDBUF and DB2_HADR_SORCVBUF:
 These two registry variables allow the users to tune the TCP socket send
and receive buffers. This does not impact the server setting for these
buffers.
 The recommendation is to set these buffers to a minimal value of
16384.
 DB2_HADR_BUF_SIZE:
 If the standby is too slow in replaying the log pages received from the
primary, its log receive buffer might fill up. In the SYNC and NEARSYNC
modes, it can cause a back up on the primary server since the standby
cannot acknowledge additional transactions.
38

 DB2_HADR_PEER_WAIT_LIMIT:
 Setting this registry variable allows the primary database to break out
of peer state incase of a blocked standby for the specified number of
seconds.
 Shared archive device:
 Using a shared archive device will speed up the catch up process.
However, using a tape drive for this can impact performance on both
primary and standby.
 Standby Configuration
 When using the read on standby feature, the standby should have
enough additional resources and sufficient catalog_cache_sz,
package_cache_sz, application heap sz and sortheap parms on standby.
39

HADR beyond High Availability
40

HADR beyond High Availability
 The HADR tool can be used beyond its conventional purpose.
 Since this is a powerful and simple replication tool, it can be used as a
database migration tool that would minimize production outage.
 For example, one of the customers had a situation where they
wanted to move the database from one physical location to
another.
 This migration required the shortest outage possible. The HADR feature
proved to be the most perfect solution in this case.
41

HADR beyond High Availability…
 All the requirements for the HADR set up were met. The
hardware, OS and DB2 versions on the target were the same.
 A week before the migration, the primary database was backed
up and restored on the target server in a rollforward pending
mode.
 All the HADR config changes were done and the firewall for
HADR ports were opened.
 HADR was started in the standby and primary. Standby went
into local catch up and then remote catch up states.
 It took some hours for the standby to sync up, but it eventually entered
the peer state.
42

HADR beyond High Availability…
 The migration window was identified where we can do a
normal take over.
 Applications were stopped. A manual take over was issued on
the standby.
 It took just a few seconds for the take over operation to
complete and the standby became the new primary.
 Applications were brought up within 10 mins. The entire
migration took under 15 mins only. Using the conventional way
would have taken more than 12 hours.
43

References
 IBM developer works technical library.
https://www.ibm.com/developerworks/data/products/db2luw/
 IBM DB2 Information centers for V8.2, V9.1, V9.5, V9.7 and
V10.1
 DB210 for LUW New Features book by Paul Zikopoulos and
other authors.
 IBM redbooks.
 DB2 Lab tech talks.
http://www-01.ibm.com/software/data/db2/tech-talk.html
44

Jeyabarathi Chakrapani
NASCO
jbchakra@gmail.com
Session D02
Evolution of the HADR tool
Evaluate my session online:
www.idug.org/na2013/eval

D02 Evolution of the HADR tool

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to D02 Evolution of the HADR tool

Similar to D02 Evolution of the HADR tool (20)

D02 Evolution of the HADR tool