HADR Setup & Configuration

Table of Contents :
1. Introduction :.....................................................................................................................1 1.1 Why choose HADR as a HA & DR solution?............................................................2 1.2 Terminology................................................................................................................3

1. Introduction :
High availability (HA) is the term used to describe systems that run and are available to customers more or less all the time. Now more than ever, customers are demanding a 24x7 operating environment. To implement this requirement, high availability and disaster recovery must be given a great deal of consideration.

DB2 High Availability Disaster Recovery (HADR) is a database replication feature that provides a high availability solution for both partial and complete site failures. DB2 HADR is designed for quick failover, easy setup, and manageability. HADR protects against data loss by replicating data changes from a source database, called the primary, to a target database, called the standby. DB2 HADR works in a similar fashion to the storage mirroring solutions, but all the work is made inside DB2 at the software level. A DB2 HADR primary database uses internal processes to ship database logs to an HADR standby database. A process at the standby server then replays these logs directly to the standby database. The standby database can be switched online in the event of a disaster, or whenever the primary requires to be temporarily taken offline for scheduled downtime.

Fig-1: Typical HADR environment HADR transmits the log records from the primary database server to the standby server. The HADR standby replays all the log records to its copy of the database, keeping it synchronized with the primary database server. The standby server is in a continuous roll forward mode and is always in a state of near-readiness, so the takeover to the standby is extremely fast. Applications can only access the primary database and have no access to the standby database. HADR gives you the ability to use a second server (that can be in sync with the primary) should the primary server fail. However the failover itself is a manual process unless you use a cluster manager (like HACMP or TSA). HACMP automates the failover so you don't need to be involved and can therefore move your failover time to sub minute (if you do it manually it will take longer than a minute for you to be notified there is a problem and then run the takeover command). So if you want sub minute failover then use cluster manager with HADR. If you want to do the takeover manually then all you need is HADR. 1.1 Why choose HADR as a HA & DR solution? The reasons to choose HADR as a solution are as follows: Ultra-fast failover capability

 Easy to set up and monitor Rolling upgrades without service interruption between non-major versions or changes requiring server recycling, and reduced change windows for other upgrades Transparent failover and failback for applications Built in clustering software in DB2 9.5 Dramatically improved disaster recovery compared to conventional methods Negligible impact on performance 1.2 Terminology Here we list and describe briefly some of the more common terms used specifically with HADR. Most of these terms can be found in various DB2 manuals or the DB2 Information Center, where you can search and see them being used in context. Generic definitions can be found in the DB2 9.5 Information Center Glossary: https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.glossary.doc/d oc/glossary.html We recommend using the Search field in the DB2 Information Center to find in-context usage of these terms:

HADR synchronization modes With HADR, you can choose the level of protection you want from potential loss of data by specifying one of the three synchronization modes: Synchronous mode: In the Peer state, the primary does not consider a transaction as committed until it gets an acknowledgment message from the standby confirming that the relevant log data has been received and written to the disk on the standby. Therefore, if a transaction is committed on the primary, it is guaranteed to be persistently stored in the standby's log file. Even if the standby crashes before it is able to replay the log, it can still replay it from its own log file when it restarts. There is no transaction loss in a Synchronous mode failover as long as the primary was in Peer state at the time of the failure. Near-synchronous mode: In the Peer state, the primary does not consider a transaction as committed until it gets an acknowledgment message from the standby confirming that the relevant log data has been received and written to the main-memory of the standby. Asynchronous mode: In the Peer state, the primary does not consider a transaction as committed until it successfully submits the relevant log data to the network. The primary does not wait for any acknowledgment message that the log data was received. Primary (database) :

This is the principal (master) copy of the database. Applications apply updates to the primary database and those updates are propagated to the standby server via log shipping. Standby (database) : This is a copy of the primary database. It is not updated directly by the application. All updates occur by rolling forward log data generated on the primary database.

Standard (database) : In the context of HADR, standard means a normally operating non-HADR database. That is, a database not using the HADR feature, and therefore not operating in either the primary or the standby mode.

Peer state: After the standby catches up with in-memory logs on the primary, HADR enters the Peer state, in which the primary ships the log page to the standby whenever it flushes a log page to the disk. The log pages are replayed on the standby as they arrive. The pages are also written to local log files on the standby so that the primary and the standby have identical log file sequences.

Catchup phase: HADR initialization always starts in the catchup phase, in which the standby tries to catch up to in-memory logs on the primary by replaying logs that have been written to the disk or the archive. During catchup, the standby can retrieve log files locally or remotely from the primary through the HADR network connection.

Takeover: Takeover is the act of the HADR standby taking over control of the database from the old primary server and becoming the new HADR primary. Takeover is always initiated from the standby. If the primary can be reached over the network as in an unforced takeover, the standby asks it to switch to standby, performing cooperative role switching. Otherwise, the standby takes action unilaterally (with the risk of dual primary/split brain). +1 4444445+897/*-/*-* Failover: Refers to changing the status of the standby in an HADR pair to become the primary, with full DB2 f****--755551689*+8886+1417/7*77unctionality, due to the original primary failing. The original primary can be brought up subsequently in the role of standby. Care must be taken to ensure that the original primary is truly non-functional at the time of failover. If both databases are functioning as primary, there is a conflict in the data update that HADR cannot resolve. The result is two incorrect versions of the database, which might be impossible to reconcile.

Failback: In the context o54847**///*//f HADR, after a failover has occurred, which made the original standby into a primary, failback is the act of reverting this database back to a

standby and bringing the original primary back as a primary once again. T7777777hat means, switching the roles of the primary and the standby, while both are alive and healthy. Failback is not a mandatory operation. A customer can choose to leave the databases in their reversed roles until another failover is necessary due to the failure of the new primary. This is especially likely in cases where the HA goal is ultra-fast failover, as failback can be viewed as a needless additional interruption in service. Failure: Failure is an event where any database service prerequisite component (DB2, operating system, server machine, or network) is no longer able to provide the service it is supposed to. HADR maintains data availability in the event of failure of any single component. If the failure affects only the standby system or the communication between the primary and the standby, data remains fully available on the primary without any disruption or required user action.

If the failure prevents the primary itself from providing DB2 functionality, the user can take the primary DB2 instance, the server, or both completely down (if it is not already) and initiate failover, which rapidly changes the standby system into a primary, making the data available again after only a brief outage. Outage period: The outage period is the amount of time it takes to failover DB2 functionality from a broken DB2 primary database to the standby. This period of time starts from the point at which failover is initiated to the point that DB2 functionality is restored. To a client connecting to the DB2 database, it is seen as a connection failure, at which point retry logic should be working to ensure that the transaction is not lost.