1. Replication Guide
  2. Administering an Active Standby Pair With Cache Groups
  3. Recovering From a Failure of the Standby Database

Recovering From a Failure of the Standby Database

To recover from a failure of the standby database, complete the following tasks:

  1. If return twosafe service is enabled, the failure of the standby database may prevent a transaction in progress from being committed on the active database, resulting in error 8170, "Receipt or commit acknowledgement not returned in the specified timeout interval". If so, then call the ttRepSyncSet built-in procedure with a localAction parameter of 2 (COMMIT) and commit the transaction again. For example: 

    Command> call ttRepSyncSet( null, null, 2);
Command> commit;

  2. Call ttRepStateSave('FAILED','standby_database','host_name') on the active database. Then, as long as the standby database is unavailable, updates to the active database are replicated directly to the subscriber databases. Additional subscriber databases may also be duplicated directly from the active.

  3. Recover the standby database in one of the following ways:

    1. Connect to the standby database. This triggers recovery from the local transaction logs. If the standby database recovers, go to Step 4; otherwise, continue to Step 3b.

    2. Destroy the current version of the standby database with the ttDestroy utility.

    3. Duplicate a new standby database from the active database. You can use either the ttRepAdmin -duplicate utility or the ttRepDuplicateEx C function to duplicate a database. Use the -keepCG -recoveringNode options with ttRepAdmin to recover and to preserve the cache group after the standby master failure. See Duplicating a Database.

  4. Set up the replication agent policy and start the replication agent on the standby database. See Starting and Stopping the Replication Agents.

  5. Start the cache agent on the standby database.

The standby database enters the STANDBY state and starts sending updates to the subscribers after the active database determines that the two master databases have been synchronized and stops sending updates to the subscribers.

Note:

You can verify that the standby database has entered the STANDBY state by using the ttRepStateGet built-in procedure.