Recovering from a Failure on the Active Cache Database

This section describes how to perform a failover to the standby cache database, after a failure on the active cache database or server. Including how to rebuild the previous active cache database from a standby cache database.

This tutorial uses the pre-defined DSN cachedb1_1121 shipped with TimesTen 11.2.1. The hostnames of the two machines are stacb12 and stach17. cachedb1_1121 was the active cache database on stacb12, and cachedb2_1121 on stach17 will be converted to become the new active cache database.

1. Stop the replication agent on the failed database

a. Stop the replication agent on the failed database if it has not already been stopped.
Log in to server 1 (stacb12) as the instance administrator, use the ttAdmin utility to stop the replication agent on cachedb1_1121
   
  ttadmin -repstop cachedb1_1121
   
 

2. Set the state of the standby cache database to active

a. In ttIsql, connect to cachedb2_1121 as the replication administrator cacheadm
   
  connect "dsn=cachedb2_1121;uid=cacheadm;pwd=cacheadm;oraclepwd=cacheadm";
 
b. Use the built-in procedure ttRepStateSet to designate the current database as the new active database in the active standby pair.
   
  call ttrepstateset('active');
   
c. Verify the current replication state by calling the built-in procedure ttRepStateGet.
   
  call ttrepstateget;
   
 
   
  Once the cache database entered the active state, it has been converted to an active database. Applications that were previously connected to the failed database can now be diverted to the new active database. See the section on Replication failover and recovery for more information.

3. Mark the previous active cache database as failed

a. Use the procedure ttRepStateSave to register the former active database as failed.
   
  call ttrepstatesave ('failed','cachedb1_1121','stacb12');

4. Stop the cache agent on the failed database

a. Stop the cache agent on the failed database if it has not already been stopped.
Log in to server 1 (stacb12) as the instance administrator, use the ttAdmin utility to stop cache agent on cachedb1_1121
   
  ttadmin -cachestop cachedb1_1121
   
 

5. Destroy the failed cache database

a. Use the ttDestroy utility to remove the failed database (cachedb1_1121) on server 1 (stacb12). Depending on the state of the database, you may have to use the -force option in ttDestroy to remove the failed database.
   
  ttdestroy cachedb1_1121

6. Duplicate the new active database to create a new standby database

a. Use the utility ttRepAdmin to create the standby database on server 1 (stacb12), by duplicating from the new active cache database.
   
  ttrepadmin -duplicate -from cachedb2_1121 -host "stach17" -uid cacheadm -pwd cacheadm -keepcg -cacheuid cacheadm -cachepwd cacheadm "dsn=cachedb1_1121"

7. Start the Replication Agent on the Standby Database

a. In ttIsql, connect to cachedb1_1121 as the replication administrator cacheadm, and use the built-in procedure ttRepStart to start the replication agent.
   
  ttisql
connect "dsn=cachedb1_1121;uid=cacheadm;pwd=cacheadm;oraclepwd=cacheadm";
call ttrepstart;
   
b. Verify that the standby cache database has entered the standby state by using the ttRepStateGet built-in procedure.
   
  call ttrepstateget;
   
 

8. Start the cache agent on the standby database

a. Call the built-in procedure ttCacheStart to start the cache agent on the standby database.
   
  call ttcachestart;

9. Attach the standby database to the cache grid (required only if global cache groups are present)

a. Step 9 is necessary only if there are global cache groups in the cache database. Call the procedure ttGridAttach to add the current standby cache database to the cache grid.
   
  call ttgridattach (1,'cachedb1','stacb12',9991,'cachedb2','stach17',9992);
   
b. Use the procedure ttGridNodeStatus to list all attached grid members and verify that cachedb1_1121 has joined the cache grid samplegrid.
   
  call ttgridnodestatus;
   
 


The configuration of an active standby pair is completed. Changes to the data in the active database will be automatically replicated to the standby database.