Switching database roles in high availability disaster recovery (HADR)

You can initiate a takeover operation on a high availability disaster recovery (HADR) standby to switch the roles of the primary and standby databases.

Before you begin

You can only perform a role switch between the primary and standby databases if the databases are in one of the following states (for Db2® pureScale® environments, if every stream meets one of these conditions):
  • peer state
  • remote catchup state, when the synchronization mode is SUPERASYNC
  • assisted remote catchup state (Db2 pureScale environments only)
If the standby database is in any other state, an error message is returned. If member or group crash recovery is in progress on the primary, the takeover operation fails.

If the log gap between the primary and standby databases is too big, then the takeover operation can run too long and possibly time-out.

About this task

The TAKEOVER HADR command can only be issued on the standby database. If the primary database is not connected to the standby database when the command is issued, the takeover operation fails. In Db2 pureScale environments, you can issue the command from any member in the standby cluster, including non-replay members.

During a role switch, the following occurs on the primary:
  1. New connections are rejected, open transactions are rolled back, and all remaining logs are shipped to the standby.
  2. The primary changes to the standby role, and log receiving and replay is started.
And the following occurs on the standby:
  1. After it has been confirmed that the old primary is now in the standby role, the standby changes its role to primary.
  2. Log receiving is stopped after the end of logs. This ensures no data loss.
  3. All received logs are replayed.
  4. The new primary database is opened for client connections.

Procedure

To switch the HADR database roles:

  • Use the CLP to initiate a takeover operation on the standby database by issuing the TAKEOVER HADR command without the BY FORCE option on the standby database.
  • Call the db2HADRTakeover application programming interface (API) from an application.
  • Open the task assistant for the TAKEOVER HADR command in IBM® Data Studio.

Example

In the following example, the takeover operation takes place on the standby database LEAFS:
TAKEOVER HADR ON DB LEAFS

A log full error is slightly more likely to occur immediately following a takeover operation. To limit the possibility of such an error, an asynchronous buffer pool flush is automatically started at the end of each takeover. The likelihood of a log full error decreases as the asynchronous buffer pool flush progresses. Additionally, if your configuration provides a sufficient amount of active log space, a log full error is even more unlikely. If a log full error does occur, the current transaction is aborted and rolled back.

Note: Issuing the TAKEOVER HADR command without the BY FORCE option causes any applications currently connected to the HADR primary database to be forced off. This action is designed to work in coordination with automatic client reroute to assist in rerouting clients to the new HADR primary database after a role switch. However, if the forcing off of applications from the primary would be disruptive in your environment, you might want to implement your own procedure to shut down such applications prior to performing a role switch, and then restart them with the new HADR primary database as their target after the role switch is completed.