Reintegrating a database after a takeover operation

If you issued a takeover operation in a high availability disaster recovery (HADR) environment because the primary database failed, you can bring the failed database back online and use it as a standby database or return it to its status as primary database.

Before you begin

Reintegration succeeds only if the old primary's log streams did not diverge from the new primary's; in a Db2® pureScale® environment, if any log stream diverges, reintegration fails. In particular, HADR requires that the original primary database did not apply any logged operation that was never reflected on the original standby database before it took over as the new primary database. If this divergence did occur, you can restart the original primary database as a standby database by restoring a backup image of the new primary database or by initializing a split mirror.

Normally, failover is performed only when the old primary is offline. But in some scenarios, it might be still online (in a Db2 pureScale environment, it might be online on some members). For example, it might have become inaccessible to clients, making a failover necessary. Do not run the DEACTIVATE DATABASE command on the old primary before reintegration because deactivation modifies the log stream, making the old primary's log stream incompatible to the new primary's. Instead, kill any remaining members on the old primary.

Because it might be necessary to kill an old primary database, it is recommended that only one HADR database be created in a Db2 instance, so that the kill does not impact other databases.

In a Db2 pureScale environment, the database must be offline on all of the old primary's members. The CF does not need to be shut down and restarted; any leftover CF data structure for this database is cleaned upon reintegration.

About this task

Successful return of the START HADR command does not indicate that reintegration succeeded; it means only that the database started. Reintegration is still in progress. If reintegration subsequently fails, the database shuts itself down. You should monitor standby states by using the db2pd command or the MON_GET_HADR table function to make sure that the standby database stays online and proceeds with the normal state transition. If necessary, you can check the administration notification log file and the db2diag log file to find out the status of the database.

Procedure

To reintegrate the failed primary database into the HADR pair as the new standby database:

Repair the system where the original primary database is located. This could involve repairing failed hardware or rebooting the crashed operating system.
Restart the failed primary database as a standby database.
In the following example, database LEAFS is started as a standby database:
```
 START HADR ON DB LEAFS AS STANDBY
```
Note: In a Db2 pureScale environment, make sure that you issue the command from the member that you want to designate as the preferred replay member

What to do next

After the original primary database rejoins the HADR pair as the standby database, you can choose to initiate a failback operation to switch the roles of the databases and return the original primary database to its initial role. To perform this failback operation, issue the following command on the standby database:

TAKEOVER HADR ON DB LEAFS

Note:

If the HADR databases are not in peer state or the pair is not connected, this command fails.
Open sessions on the primary database are forced closed and inflight transactions are rolled back.
When you are switching the roles of the primary and standby databases, you cannot specify the BY FORCE option of the TAKEOVER HADR command.