Choice of SUPERASYNC mode for disaster recovery using DB2 HADR

DB2® High Availability Disaster Recovery (HADR) is an easy-to-use data replication feature of IBM® DB2 for Linux®, UNIX®, and Windows® that provides a high availability (HA) solution for both partial and complete site failures. Beginning with DB2 V9.5 Fix Pack 8 and DB2 V9.7 Fix Pack 5, a new HADR sync mode called SUPERASYNC has been introduced. This article explains the purpose of SUPERASYNC mode, the deployment of a HADR pair using this mode, as well as standby state transition in this mode. In addition, it includes use case scenarios that explain the implementation of SUPERASYNC mode for disaster recovery. It will also look at how Primary will overcome the back pressure and perform better in case of single or multiple standby, and what the benefits and drawbacks are from using this mode.

Vishnu Priya G (goppriya@in.ibm.com), DB2 System Software Engineer, IBM

Author photo of VishnuVishnu Priya G has been working as a system verification engineer for DB2 for Linux, UNIX, and Windows since 2010. She is an IBM DB2 certified Advanced DBA, and has been an active member of the team that verifies the HADR feature. Her area of expertise is DB2 High Availability Disaster Recovery.



Hemant Singh (hemant_singh@in.ibm.com), DB2 Staff Software Engineer, IBM

Author photo newHemant K Singh has been working as a staff software engineer in System Verification Testing for DB2 since June 2006. He is an IBM DB2 Certified V9 Advanced DBA. His area of expertise is DB2 High Availability Disaster Recovery (HADR) and Extent Movement.



14 February 2013

Also available in Chinese

Introduction and background

HADR is a DB2 feature that provides high availability and disaster recovery via data replication. When enabled, database logs from the Primary database are shipped to the standby database in real time. The standby database continuously replays the received logs to stay in sync with the Primary database.

Starting with DB2 V9.5 Fix Pack 8 and DB2 V9.7 Fix Pack 5, SUPERASYNC can be specified as hadr_syncmode, where Primary can never be blocked in any case.

This article explains the purpose of SUPERASYNC mode, how you can set up HADR in this mode, as well as the different transition states of standby in this mode. It includes use cases that suit implementation of SUPERASYNC mode including the pros and cons of using it.


Purpose of SUPERASYNC mode

You may face an issue where the Primary is blocked due to the slowness in the replay of logs at the standby side due to network hiccups or lack of resources on the standby. The SUPERASYNC mode has been introduced to prevent any back pressure (slowing/blocking the transactions) on Primary caused by network hiccups or slow performing standby.


How HADR works in SUPERASYNC mode

In SUPERASYNC mode, HADR EDU does the log shipping in the background, and does not interfere with the code path of the transaction, which means log shipping is out of the loop for committing transactions. Hence, it will not block the Primary from running the transactions.

The HADR pair will never enter Peer state or Disconnected Peer state. The HADR state will move from local catch up to remote catch up, and then stays in remote catch up. HADR will always ship logs from Primary on disk or archived logs. It will not enter peer state where logs are shipped from the Primary database log buffer, and the Primary database log writer can be slowed down.

This gives the best performance when compared to the other sync modes as shown in Figure 1.

Figure 1. Working of HADR in SUPERASYNC
Working of HADR in SuperAsync mode
  1. Primary writes the log records to the log files of the primary database.
  2. It then commits the transaction without waiting for log replication to the standby.

Setting up HADR pair in SUPERASYNC mode

To set up the HADR pair in SUPERASYNC mode, update the HADR_SYNCMODE db cfg parameter with SUPERASYNC as shown in Listings 1 through 3.

Listing 1. Update HADR_SYNCMODE
$ db2 update db cfg for hadrdb using HADR_SYNCMODE SUPERASYNC
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. 
SQL1363W One or more of the parameters submitted for immediate modification
were not changed dynamically. For these configuration parameters, the database
must be shutdown and reactivated before the configuration parameter changes
become effective.
Listing 2. Deactivate database
$ db2 deactivate db hadrdb
DB20000I The DEACTIVATE DATABASE command completed successfully.
Listing 3. Activate database
$ db2 activate db hadrdb
DB20000I The ACTIVATE DATABASE command completed successfully.

The state of a Primary or standby can be monitored using the MON_GET_HADR (this may not be available in V9.7) table function or the db2pd command with -hadr option.

For example,

$db2pd –db dbname -hadr

HADR state transition in SUPERASYNC mode

As shown in Figure 2, when a standby database is started, it enters Local catchup state and reads the log files that are available in the local log path. Once it reads the local log files, standby will enter into Remote catchup pending state and wait for the Primary connection. Once the Primary database is connected to a standby database, they will stay in Remote catchup state and will never get into Peer state to avoid back pressure on Primary.

Figure 2. States of the standby database in SUPERASYNC mode
Different states of the standby database in SUPERASYNC mode

When Primary and standby are connected in SUPERASYNC mode, the state of the standby will be RemoteCatchup, as shown in Figure 3.

Figure 3. Standby state as Remote catchup
Standby state as RemoteCatchup

When the standby becomes unavailable, Primary state will be Disconnected as shown in Figure 4.

Figure 4. Primary state as disconnected when standby is unavailable
Primary state as Disconnected when standby is unavailable

And when the standby loses connection to Primary, the standby state will be RemoteCatchupPending as shown in Figure 5.

Figure 5. Standby state as RemoteCatchupPending
Standby state as RemoteCatchupPending

DB2 disaster recovery scenarios where SUPERASYNC is configured

The following section describes the use case scenarios where SUPERASYNC can be configured as hadr_syncmode, and how it helps in disaster recovery with better Primary performance.

DB2 disaster recovery using HADR and HA using cluster service

The following scenario is applicable for DB2 V9.7

Let's say Primary is set up in Location 1 for high availability between two machines (M1 and M2) using TSA or HACMP cluster service. The standby is set up in Location 2 for disaster recovery using HADR replication process in SUPERASYNC mode as shown in Figure 6.

Figure 6. DR using SUPERASYNC
Disaster Recovery using HADR in superasync mode

User applications connect and execute transactions on the primary server, such as M1. The logs will be shipped to the standby server from M1. Since standby is set up in SUPERASYNC mode there will not be any back pressure on Primary due to its distance from Primary (high network latency) or network hiccups. Hence, Primary's performance will be good.

In case M1 on the Primary side (at Location 1) goes down, the other node which is set up for high availability such as Machine M2 in Location 1 is brought up automatically by the cluster service.

After this HA failover, log shipping will be performed from M2 to standby via HADR replication process. If Location 1 goes down (both M1 and M2 are down), standby can be brought up as Primary. Through this kind of setup, you can achieve best performance with high availability of database as well as recovery of database in case of disaster.

Multiple standby for DR using HADR in SUPERASYNC

The following scenario is applicable for DB2 V10.1

In HADR with multiple standby you can have up to three standby databases, which is a new feature in DB2 V10.1. One of these databases can be designated as Principal standby (which supports all the HADR sync modes), and others as auxiliary standby databases (which supports only SUPERASYNC mode). Principal standby can be deployed in the same location as Primary. Auxiliary standbys can be deployed in a distant location which can provide protection from the disaster at Primary and principle locations.

The following are the two possible scenarios to set up multiple standby for disaster recovery using HADR in SUPERASYNC mode.

  • Scenario 1: DB2 high availability and disaster recovery using HADR
  • Scenario 2: DB2 high availability and multiple DR using HADR

Scenario 1: DB2 high availability and disaster recovery using HADR

In this scenario, high availability has been set up between Primary and Principal standby at Location 1 using TSA cluster service. Auxiliary standby is set up for DR at Location 2, as shown in Figure 7.

Figure 7. HA and DR using multiple standby
High Availability and Disaster Recovery using Multiple standby in superasync mode

User applications connect and execute transactions on the Primary server. Transaction logs will be shipped from the Primary to the Principal and auxiliary standby servers. Since auxiliary standby is set up in SUPERASYNC, there will not be any back pressure on Primary due to its distance from Primary (high network latency) or network hiccups.

If there is an outage on the Primary, Principle standby will be brought up as Primary automatically using the cluster service (TSA), and now the new Primary ships the logs to the standby at Location 2.

If any disaster occurs at Location 1 (both Primary and Principal standby are down), then the standby at Location 2 can be brought up as Primary. Since you used the SUPERASYNC mode at the disaster recovery site, you can achieve the best performance at Primary by avoiding back pressure due to distant location or network delay.

Scenario 2: DB2 high availability and multiple DR using HADR

In this scenario, high availability has been set up between Primary and Principal standby at Location 1 using TSA cluster service. For disaster recovery, Auxiliary standby1 is set up at Location 2, and Auxiliary standby2 is set up at Location 3, as shown in Figure 8.

Figure 8. HA and multiple DR using multiple standby
High Availability and multiple Disaster Recovery using Multiple standby

User applications connect and execute transactions on the Primary server. Transaction logs are shipped from the Primary to the Principal standby and also to both auxiliary standby servers. Since auxiliary standbys are set up in SUPERASYNC, these will not affect the activity on Primary due to the distance or the network delay.

If there is an outage on the Primary, Principle standby will be brought up as Primary automatically using the cluster service (TSA), and now the logs will be shipped from the new Primary to other standbys.

If any disaster occurs at Location 1, one of the auxiliary standbys will be brought up as Primary, and applications will be connecting to this new Primary and logs will be sent from new Primary to the remaining standby. Since you used the SUPERASYNC mode at disaster recovery sites, you can achieve the best performance at Primary by avoiding back pressure due to distant location or network delay.


Conclusion

In this article, you have learned the benefits and drawbacks of using SUPERASYNC mode, which are as follows.

  1. The transaction response time in this mode is shorter than all other synchronization modes. But it has the highest probability of transaction losses if any failure occurs on the Primary system. This mode is useful when you do not want your transactions on Primary to be blocked or experience prolonged response times due to network-related problems.
  2. Transaction commits on Primary database is not affected by the HADR network or the standby server. This might cause the continuous increase in the log gap between the Primary database and standby database. A large log gap would result in a long graceful takeover time. All data in the log gap will be lost if any disaster occurs on the Primary system. Hence it is important to monitor the log gap using the hadr_log_gap monitor element or db2pd –hadr command. If you observe that the log gap is not acceptable, investigate the network performance or the relative speed of the standby database and take corrective actions to control the log gap.

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.
  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=857759
ArticleTitle=Choice of SUPERASYNC mode for disaster recovery using DB2 HADR
publish-date=02142013