d02 evolution of the hadr tool

Evolution of the DB2 HADR toolJeyabarathi(JB) ChakrapaniNASCOSession Code: D02April 30, 2-3 PM | Platform: DB2 LUW

Click to edit Master title style2

Evaluate my session online: www.idug.org/na2013/eval

http://www.idug.org/na2013/eval

Click to edit Master title style

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.


Brief introduction to DB2 HADR

IBM first introduced HADR in version 8.2. Since then it hasbecome a powerful feature within DB2 to provide a true disasterrecovery solution for business critical databases.

HADR is basically a log based replication tool. DB2 writes a log filefor each database change(except for a few changes that are notlogged) and the HADR tool reads these logs from the primaryserver 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.

Brief introduction to DB2 HADR


HADR Setup

Database E

HADR HADRTCP/IP

Primary Standby

Database A

HADR HADRTCP/IP

Standby Primary

Database A

Database E


Activelogs

Archivelogs

TablesIndexes

HADR HADRTCP/IP

PRIMARY SERVER

DatabaseDirectory

SECONDARY SERVER

DatabaseDirectory

Activelogs

Archivelogs

TablesIndexes

Backup the

primary

Restore on standby


Synchronization modes

logs

log writer

HADR

logs

HADR

Commit Succeeded

Synchronous

Near- SynchronousAsynchronous

Synchronous, Near Synchronous, Asynchronous

receive()send()

Commit Request

commit

send receive


HADR Setup


HADR Setup.. Choose the mode for HADR sync up. There are four modes tochoose 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…

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.


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.


Evolution of the tool from version to version.


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


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.


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.


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.



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.



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



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.



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.



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.


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.


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.


Primary

PrincipalStandby

AuxiliaryStandby 2

AuxiliaryStandby 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.



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.



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.


How to set up HADR on your DB2 servers


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


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.


How to set up HADR on your DB2 servers…

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


How to set up HADR on your DB2 servers…

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.


HADR performance tuning


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.



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.



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.


HADR beyond High Availability


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.


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.


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.


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

https://www.ibm.com/developerworks/data/products/db2luw/

Jeyabarathi [email protected] D02Evolution of the HADR tool

Evaluate my session online: www.idug.org/na2013/eval

http://www.idug.org/na2013/eval

d02 evolution of the hadr tool

Documents