Active Standby Pair
with In-Memory Database Cache

An active standby pair configuration includes an active cache database, a standby cache database, and optional read-only subscriber databases. The standby cache database receives the updates from the active cache database, and forwards the changes to optional read-only subscriber databases. All updates go directly to the active cache database. The standby cache database is also available for read-only applications, for example a reporting server.

This section describes how you can set up and administer an active standby pair where cache tables are replicated in real-time for high availability. Before you can set up an active standby pair, the In-Memory Database Cache 11.2.2 software needs to be installed on both the active and standby servers, the connections to the Oracle database need to be configured, and the instance administrator user name must be the same on both installations.

Setting up an Active Standby Pair

Here is an overview of the configuration steps for setting up an active standby pair on a cache database.

1. Create a cache database An initial cache database must be created before an active standby pair can be set up. This database should contain a user with CACHE_MANAGER or ADMIN privilege for managing a cache grid, with the required cache groups already defined. Please refer to Configuration for IMDB Cache and Cache Grid for more information on how to set up a cache database.

If you have an existing cache database, this step can be skipped.
2. Create a user to administer the active standby pair The cache database must include a user with the ADMIN privilege if not yet already existing. This user will be responsible for managing the active standby configuration.
3. Detach database from the cache grid Use the ttGridDetach built-in procedure to detach the database from the cache grid if already attached.
4. Start the cache agent Use the built-in procedure ttCacheStart to start the cache agent process if not already started.
5. Set autorefresh state to paused If there are any autorefresh cache groups their state must be temporarily set to paused before an active standby pair can be defined. Use the ALTER CACHE GROUP SQL statement to change the autorefresh state
6. Stop the replication agent Use the built-in procedure ttRepStop to temporary stop the replication agent process if not already stopped.
7. Define an active standby pair replication scheme Define the configuration of the active standby pair including the hostnames and the data store names of both the Active and Standby Databases using the CREATE ACTIVE STANDBY PAIR SQL statement.
8. Set the state of the database to active Use the built-in procedure ttRepStateSet to designate the current database as the active database.
9. Start the replication agent A replication agent process is responsible for replicating data between TimesTen databases.
Use the built-in procedure ttRepStart to start the replication agent.
10. Duplicate the active database to the standby server The standby database is created by cloning the active database to the standby server. Use the ttRepAdmin utility to duplicate the active database to the standby server.
11. Attach the active database to the cache grid If global cache groups are defined in the cache database, or if global cache grid operations are required, use the ttGridAttach built-in procedure to register the active database into the cache grid, specifying the host names and database names for both the active and standby databases.
12. Start the replication agent on the standby database The replication agent on the standby is responsible for receiving data from the active database. Use the built-in procedure ttRepStart to start the replication agent process.
13. Start the cache agent on the standby database Use the built-in procedure ttCacheStart to start the cache agent process.
14. Attach the standby database to the cache grid If global cache groups are defined in the active cache database, or if global cache grid operations are required, use the ttGridAttach built-in procedure to register the standby database into the cache grid, specifying the host names and database names for both the active and standby databases.
15. Preload data into cache groups Use the LOAD CACHE GROUP statement to preload the cache groups with data from the Oracle database.

Follow the examples below to set up an active standby pair using the configuration steps described above:

  1. Setting Up an Active Master Cache Database
  2. Configuring an Active Standby Pair for the Cache Database
  3. Creating a Standby Cache Database

Recovering from a failure on the active cache database

Here is an overview of the configuration steps for recovering from a failure on the active cache database. This will perform a failover to the standby database and recover the failed active database. The steps below are appropriate for both asynchronous and return receipt replication.

1. Stop the replication agent on the failed active cache database Stop the replication agent on the failed database if it has not already been stopped. Use the built-in procedure ttRepStop to stop the replication agent.
2. Set the state of the standby database to active Use the built-in procedure ttRepStateSet to designate the current standby database as the new active database in the active standby pair. This will also change the autorefresh state of cache groups from "paused" to "on".
3. Mark the previous active database as failed Execute the built-in procedure ttRepStateSave on the new active database to register the former active database as failed.
4. Stop the cache agent on the failed database Use the built-in procedure ttCacheStop to stop the cache agent on the failed database if not already stopped.
5. Destroy the failed database Use the ttDestroy command to remove the failed cache database.
6. Duplicate the new active database to create a new standby database Use ttRepAdmin to duplicate from the new active database to the new standby database.
7. Start the replication agent on the new standby database Use the built-in procedure ttRepStart to start the replication agent process.
8. Start the cache agent on the new standby database Use the built-in procedure ttCacheStart to start the cache agent process.
9. Attach the standby database to the cache grid If Global Cache Groups are defined in the active cache database, use the ttGridAttach built-in procedure to register the standby database into the cache grid, specifying the host names and database names for both the active and standby databases.

The Recovering from a Failure on the Active Cache Database example shows how to failover to a standby database using the steps described above.


Dropping an Active Standby Pair

Here is an overview of the configuration steps for removing an active standby pair configuration from a cache database. This will remove the standby cache database, and revert the configuration back to a single cache database.

1. Detach the databases from the cache grid If global cache groups are defined, use the ttGridDetach built-in procedure to detach both the active and standby databases from the cache grid.
2. Stop the replication agents Use the built-in procedure ttRepStop to stop the replication agents on each database.
3. Remove the active standby pair scheme Remove the active standby pair schema by using the DROP ACTIVE STANDBY PAIR SQL statement on each database.
4. Remove cache groups from the previous standby database Use the DROP CACHE GROUP SQL statement to remove cache groups from the redundant standby database.
5. Stop the cache agent on the previous standby database Use the built-in procedure ttCacheStop to stop the cache agent on the previous Standby database.
6. Destroy the previous standby cache database Use the ttDestroy command to remove the redundant standby database
7. Attach the database to the cache grid If global cache groups are defined in the cache database, use the ttGridAttach built-in procedure to attach the database back into the cache grid.

The Dropping an Active Standby Pair Configuration example shows how to remove an active standby pair and to revert back to a standalone cache database by following the steps above.