Upload
jeyabarathi-jb-chakrapani
View
262
Download
3
Embed Size (px)
Citation preview
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
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
Click to edit Master title style4
Brief introduction to HADR and how it works to provide high availability.
Click to edit Master title style
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
Click to edit Master title style6
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
Click to edit Master title style
HADR Setup
Database E
HADR HADRTCP/IP
Primary Standby
Database A
HADR HADRTCP/IP
Standby Primary
Database A
Database E
Click to edit Master title style
Activelogs
Archivelogs
TablesIndexes
HADR HADRTCP/IP
PRIMARY SERVER
DatabaseDirectory
SECONDARY SERVER
DatabaseDirectory
Activelogs
Archivelogs
TablesIndexes
Backup the
primary
Restore on standby
Click to edit Master title style
Synchronization modes
logs
log writer
HADR
logs
HADR
Commit Succeeded
Synchronous
Near- SynchronousAsynchronous
Synchronous, Near Synchronous, Asynchronous
receive()send()
Commit Request
commit
send receive
Click to edit Master title style10
HADR Setup
Click to edit Master title style11
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.
Click to edit Master title style12
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
Click to edit Master title style13
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.
Click to edit Master title style14
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.
Click to edit Master title style15
Evolution of the tool from version to version.
Click to edit Master title style16
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
Click to edit Master title style17
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.
Click to edit Master title style18
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.
Click to edit Master title style19
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.
Click to edit Master title style20
HADR features in V9.1..
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.
Click to edit Master title style21
HADR features in V9.1..
Other new registry variable available with HADR on V9.1: DB2_HADR-PEER_WAIT_LIMIT – V9.1 fp4
Click to edit Master title style22
HADR features in V9.5
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.
Click to edit Master title style23
HADR features in V9.5
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.
Click to edit Master title style24
HADR features in V9.7
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.
Click to edit Master title style25
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.
Click to edit Master title style26
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.
Click to edit Master title style
Primary
PrincipalStandby
AuxiliaryStandby 2
AuxiliaryStandby 1
Any sync mode
Super Async
Super Async
Location A Location B
Multiple Standby
Multiple standby set up
Click to edit Master title style28
HADR features in V10…
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.
Click to edit Master title style29
HADR features in V10…
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.
Click to edit Master title style30
HADR features in V10…
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.
Click to edit Master title style31
How to set up HADR on your DB2 servers
Click to edit Master title style32
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
Click to edit Master title style33
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.
Click to edit Master title style34
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
Click to edit Master title style35
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.
Click to edit Master title style36
HADR performance tuning
Click to edit Master title style37
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.
Click to edit Master title style38
HADR performance tuning…
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.
Click to edit Master title style39
HADR performance tuning…
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.
Click to edit Master title style40
HADR beyond High Availability
Click to edit Master title style41
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.
Click to edit Master title style42
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.
Click to edit Master title style43
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.
Click to edit Master title style44
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
Jeyabarathi [email protected] D02Evolution of the HADR tool
Evaluate my session online: www.idug.org/na2013/eval