(go) Use DB2 HADR to select the SUPERASYNC mode for disaster recovery

Use DB2 HADR to select the SUPERASYNC mode for disaster recovery Vishnu G and Hemant Singh
published on June 25, 2013

Weibogoogle+ send this page by e-mail

0 Introduction and background

HADR is a DB2 feature that provides high availability and disaster recovery through data replication. When this feature is enabled, the primary database data logs can be delivered to the standby database in real time. The standby database continues to replay the logs that have been received in order to stay in sync with the primary database.

Starting with DB2 V9.5 Fix Pack 8 and DB2 V9.7 fix Pack 5, SUPERASYNC is designated as Hadr_syncmodeso that the primary database is not blocked under any circumstances.

This article describes the purpose of the SUPERASYNC pattern, how to set up HADR in this mode, and the transition state of different standby databases in this mode. This article provides a use case for implementing the SUPERASYNC pattern, and also describes the pros and cons of using it.

Use of the SUPERASYNC mode

You may be faced with a blocking problem with the primary database because the standby log replay is slow, and the standby log replay is slow because the standby system lacks resources and a network pause occurs. The introduction of the SUPERASYNC mode prevents major database back-pressure (slowing/blocking transactions) due to network pauses or slow execution of standby.

How HADR works in SUPERASYNC mode

In SUPERASYNC mode, HADR EDU sends logs in the background and does not interfere with the code path of the transaction, which means that the log send is not within the scope of the commit transaction. Therefore, it does not prevent the primary database from running transaction processing.

HADR pairs will never enter peer State or disconnected peer state. The HADR state will gradually change from local catch up to remote catch up, and then stay on the remote catch up. HADR always sends logs from the primary database of disk or archived logs. It does not need to enter Peer state, where logs are sent from the primary database log buffers, and the write program for the primary database log is slowed down.

This mode provides the best performance when compared to the other synchronization modes shown in Figure 1.

Figure 1. How HADR works in SUPERASYNC

1. The primary database writes log records to the log files of the primary database.
2. The transaction is then committed without waiting for the log to be copied to the standby database.

To set the HADR pair in SUPERASYNC mode

To set up the HADR pair in SUPERASYNC mode, you can update the Hadr_syncmode db cfg parameter with the SUPERASYNC parameter shown in Listing 1 to listing 3.

Listing 1. Update Hadr_syncmode

123456

$ db2 update db cfg for hadrdb using HADR_SYNCMODE SUPERASYNCDB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. SQL1363W One or more of the parameters submitted for immediate modificationwere not changed dynamically. For these configuration parameters, the databasemust be shutdown and reactivated before the configuration parameter changesbecome effective.

Listing 2. Deactivate a database

12	$ db2 deactivate db hadrdbDB20000I The DEACTIVATE DATABASE command completed successfully.

Listing 3. Activating the database

12	$ db2 activate db hadrdbDB20000I The ACTIVATE DATABASE command completed successfully.

Monitor the state of the primary or standby database with a table function that may not be available in V9.7 or a DB2PD command with-HADR option Mon_get_hadr.

For example

1	$db2pd –db dbname -hadr

HADR state transitions in SUPERASYNC mode

As shown in 2, when the standby database is enabled, the database enters the local catchup state and reads the log files that are available on the native log path. After the local log file is read, the standby database enters the Remote catchup pending state and waits for the connection of the primary database. Once the primary database is connected to the standby database, they remain in the Remote catchup state and are no longer in Peer state to avoid generating primary database backpressure.

Figure 2. Standby database state in SUPERASYNC mode

When the primary and standby databases are connected in SUPERASYNC mode, the state of the standby database will be the remotecatchupshown in Figure 3.

Figure 3. The status of the standby database is Remote catchup

When the standby database is unavailable, the status of the primary database will be disconnected, as shown in 4.

Figure 4. The state of the primary database is disconnected when the standby database is unavailable

When the standby database disconnects from the primary database, the state of the standby database is remotecatchuppending, 5.

Figure 5. The state of the standby database is remotecatchuppending

SUPERASYNC configuration in the DB2 disaster recovery scenario

The following subsections describe the use case scenarios where SUPERASYNC can be configured as Hadr_syncmode and how it helps to achieve better primary database performance for disaster recovery.

DB2 disaster recovery through cluster services using HADR and HA

The following scenarios apply to DB2 V9.7.

For example, establishing a primary database in Location 1 enables high availability between two machines (M1 and M2) that use a TSA or HACMP Cluster service. Establish a standby database in location 2 to enable disaster recovery using the HADR replication process in SUPERASYNC mode, as shown in 6.

Figure 6. Disaster recovery with SUPERASYNC

The user application connects and executes transactions on the primary database, such as M1. The log is sent from M1 to the standby database. Because the standby database was established in SUPERASYNC mode, the primary database back pressure is not generated because it is away from the primary database (high network latency) or network pauses. Therefore, the main database performance is better.

If the M1 speed on the primary database (location 1) drops, then the Cluster service will start enabling another node that is set to high availability (for example, machine M2 in Location 1).

After the HA failover is completed, logs are sent from M2 to the standby database through the HADR replication process. If location 1 slows down (both M1 and M2 fall). The standby database will be enabled as the primary database. With this setup, you can get the best performance for database high availability and database recovery to prevent disaster.

Use HADR to build multiple standby databases in SUPERASYNC mode for disaster recovery

The following scenarios apply to DB2 V10.1

There are up to three standby databases in HADR with multiple standby databases, a new feature in DB2 V10.1. One of the databases can be designed as the primary standby database (all HADR synchronization modes are supported), and the other two are used as secondary standby databases (only SUPERASYNC mode is supported). The primary standby database can be deployed as the primary database in the same location. The secondary standby database is deployed remotely, providing protection for the primary database and the primary standby to prevent a disaster from occurring.

The following are two possible scenarios for disaster recovery by using HADR to build multiple standby databases in SUPERASYNC mode.

• Scenario 1: Using HADR for DB2 high availability disaster recovery
• Scenario 2: Using HADR for DB2 high availability and multiple disaster recovery

Scenario 1: Using HADR for DB2 high availability and disaster recovery

In this scenario, the TSA Cluster service is used on location 1 to set up high availability between the primary database and the primary standby database. The secondary standby database is set to implement disaster recovery on location 2, as shown in 7.

Figure 7. Use multiple standby databases for high availability and disaster recovery

The user application connects and executes transactions on the primary server. The transaction log is sent from the primary server to the primary standby server and to the secondary standby server. Because the secondary standby server is established in SUPERASYNC mode, it does not generate any back pressure on the primary server because it is away from the primary server (high network latency) or network pauses.

If a primary server outage occurs, the primary standby server will be automatically enabled as the primary server using the Cluster service (TSA), and the new primary server will now send logs to the standby server on location 2.

If a disaster occurs on location 1 (the primary server and the primary standby server are simultaneously down), then the standby server on location 2 can be enabled as the primary server. Because you use the SUPERASYNC mode on the disaster recovery site, you can achieve optimal performance on the primary server by avoiding back pressure due to long distance or network latency.

Scenario 2: Using HADR for DB2 high availability and multiple disaster recovery

In this scenario, you can use the TSA Cluster service on location 1 to establish high availability between the primary server and the primary standby server. For disaster recovery, a secondary standby server 1 can be established on location 2, and a secondary standby server at location 3 is established at 2, as shown in 8.

Figure 8. Use multiple standby servers for high availability and multiple disaster recovery

The user application establishes a connection and executes transactions on the primary server. The transaction log is transferred from the primary server to the primary standby server, and also to two secondary standby servers. Because the secondary standby server is established in SUPERASYNC mode, activities on the primary server are not affected by distance or network latency.

If the primary server fails, the primary standby server is automatically enabled as the primary server by using the Cluster Service (TSA), and logs are sent from the new primary server to the other standby server.

If a disaster occurs on location 1, one of the secondary standby servers is enabled as the primary server, and the application connects to the new primary server and sends the logs to the remaining standby servers from the primary server. Because you use the SUPERASYNC mode on the disaster recovery site, you can achieve optimal performance on the primary server by avoiding back pressure due to long distance or network latency.

Conclusion

In this article, you have learned about the advantages and disadvantages of using the SUPERASYNC model, namely:

1. In SUPERASYNC mode, transaction response times are shorter than in all other synchronization modes. However, if the primary system fails, the likelihood of transaction loss is greatest. This mode is useful if you do not want transactions on the primary system to be blocked by network problems or to experience longer response times.
2. Transaction commits on the primary database are not affected by the HADR network or the standby server. This may result in a continuous increase in log gaps (log gap) between the primary database and the standby database. Large log blanks can lead to lengthy recovery times. If a disaster occurs on the primary system, all data in the log blank will be lost. Therefore, it is important to monitor the log whitespace using the HADR_LOG_GAP monitoring element or the DB2PD–HADR command. If you observe unacceptable log whitespace, you should investigate the network performance or the relative speed of the standby database, and take corrective action to control log whitespace.

(go) Use DB2 HADR to select the SUPERASYNC mode for disaster recovery