with TimesTen In-Memory Database
Anconfiguration includes an active database, a standby database, and optional read-only subscriber databases. The standby database receives the updates from the active database, and forwards the changes to optional read-only subscriber databases. All updates go directly to the active database. The standby 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. Before you can set up an active standby pair, the TimesTen 11.2.2 database software needs to be installed on both the active and standby servers, 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 with a TimesTen in-memory database:
|1.||Create a database||In order to set up an active standby pair configuration, you need to first have a running database.
This database should include one or more tables owned by an application user. All tables must also have a primary key index.
If you have an existing database, this step can be skipped.
|2.||Create a user to administer the active standby pair||This database must include a user with ADMIN privilege. This user is the replication administrator responsible for managing the active standby configuration.|
|3.||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 theSQL statement.|
|4.||Set the state of the database to active||Use the built-in procedureto designate the current database as the active database.|
|5.||Start the replication agent||The replication agent process is responsible for replicating data between TimesTen databases. Use the built-in procedureto start the replication agent.|
|6.||Duplicate the active database to a standby server||The standby database is created by cloning the active database to the standby server. Use theutility to duplicate the active database to the standby server.|
|7.||Start the replication agent on the standby database||The replication agent process on the standby is responsible for receiving data from the active database.
Use the built-in procedure
to start the replication agent.|
Once the agent is up, the database will automatically enter "standby" mode. Changes from the active database will be propagated to the standby database.
|8.||Verify the replication between active and standby||Perform updates on the active database and ensure the changes are being replicated to the standby database.|
Follow the examples below to set up an active standby pair using the configuration steps described above:
- Setting up an Active Master Database
- Defining an Active Standby Pair Configuration
- Creating a Standby Database
Recovering from a Failure on the Active Database
Here is an overview of the configuration steps for recovering from a failure on the active 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 database||Use the built-in procedureto stop the replication agent process on the failed database, if it has not already been stopped.|
|2.||Set the state of the standby database to active||Use the built-in procedureto designate the current standby database as the new active database in the active standby pair.|
|3.||Mark the previous active database as failed||Execute the built-in procedureon the new active database to register the former active database as failed.|
|4.||Destroy the failed database||Use theutility to remove the failed database.|
|5.||Duplicate the new active database to create a new standby database||Useto duplicate from the new active database to the new standby database.|
|6.||Start the replication agent on the standby database||Use the built-in procedureto start the replication agent. Once the agent is up, the database will automatically enter the "standby" state. Changes from the new active will be propagated to the new standby.|
Follow the example below to failover to a standby database using the steps described above:
Recovering from a Failure on the Active Database example
Dropping an Active Standby Pair
Here is an overview of the steps needed to remove an active standby pair configuration from a TimesTen in-memory database. This will remove the standby database, and revert back to a single standalone database.
|1.||Stop the replication agents||Use the built-in procedureto stop the replication agent on each database.|
|2.||Remove the active standby pair scheme||Remove the active standby pair schema by using theSQL statement on each database.|
|3.||Destroy the standby database||Use theutility to remove the redundant standby database.|
Follow the example below to remove an active standby pair, and revert back to a standalone database using the steps described above:
Dropping an Active Standby Pair Configuration example