1. Replication Guide
  2. Administering an Active Standby Pair Without Cache Groups
  3. Recovering After a Dual Failure of Both Active and Standby Databases

Recovering After a Dual Failure of Both Active and Standby Databases

If both the active and standby databases fail, you can choose how to recover both databases.

Consider the following scenarios:

  • The standby database fails. Then, the active database fails before the standby comes back up or before the standby has been synchronized with the active database.

  • The active database fails. The standby database becomes ACTIVE, and the rest of the recovery process begins. (See Recovering From a Failure of the Active Database.) The new active database fails before the new standby database is fully synchronized with it.

In both scenarios, the subscribers may have had more changes applied than the standby database.

When the active database fails and the standby database has not applied all of the changes that were last sent from the active database, there are two choices for recovery:

  • Recover the active database from the local transaction logs.

  • Recover the standby database from the local transaction logs.

The choice depends on which database is available and which is more up to date.

Recover an Active Database

Perform a few tasks to recover an active database.

  1. Connect to the failed active database. This triggers recovery from the local transaction logs.
  2. Verify that the replication agent for the failed active database has restarted. If it has not restarted, then start the replication agent. See Starting and Stopping the Replication Agents.
  3. Call ttRepStateSet('ACTIVE') on the newly recovered database.
  4. Continue with Step 6 in Setting Up an Active Standby Pair With No Cache Groups.

Recover a Standby Database

Perform a few tasks to recover a standby database.

  1. Connect to the failed standby database. This triggers recovery from the local transaction logs.
  2. If the replication agent for the standby database has automatically restarted, you must stop the replication agent. See Starting and Stopping the Replication Agents.
  3. Drop the replication configuration using the DROP ACTIVE STANDBY PAIR statement.
  4. Re-create the replication configuration using the CREATE ACTIVE STANDBY PAIR statement.
  5. Call ttRepStateSet('ACTIVE') on the master database, giving it the ACTIVE role.
  6. Set up the replication agent policy and start the replication agent on the new standby database. See Starting and Stopping the Replication Agents.
  7. Continue from Step 6 in Setting Up an Active Standby Pair With No Cache Groups.