Replicating Cache Groups Within Active Standby Pairs

An active standby pair that replicates a read-only cache group or an asynchronous writethrough (AWT) cache group can change the role of the cache group automatically as part of failover and recovery. This helps ensure high availability of cache instances with minimal data loss.

See Replicating an AWT Cache Group and Replicating a Read-Only Cache Group to understand the benefits of using cache groups within an active standby pair.

Note:

TimesTen does not support replication of a user managed cache group or a synchronous writethrough (SWT) cache group in an active standby pair.

The following sections describe how to set up an active standby pair with cache groups:

You can also create a special disaster recovery read-only subscriber when you set up active standby replication of an AWT cache group. This special subscriber, located at a remote disaster recovery site, can propagate updates to a second Oracle database, also located at the disaster recovery site. See Using a Disaster Recovery Subscriber in an Active Standby Pair.

Setting Up an Active Standby Pair with an AWT Cache Group

With the active standby pair replication scheme, you must replicate all AWT cache groups. You can create the cache groups on the active master either before or after the active standby pair replication scheme is created.

Before the creation of active standby pair: You can create cache groups on the active master before the active standby pair replication scheme is created. Then, create the active standby pair replication scheme and perform a distribution to include the cache groups. For detailed instructions on creating AWT cache group and then including it within a new active standby pair , see Replicating Cache Tables in TimesTen Classic in Oracle TimesTen In-Memory Database Cache Guide.
After creation of active standby pair: You can create cache groups on the active master after the active standby pair replication scheme is created. Then, perform a distribution to include the cache groups. See Making Other Changes to an Active Standby Pair.

Either way, cache groups are added to the active standby pair replication scheme after you perform a distribution to include these cache groups.

Setting Up an Active Standby Pair with a Read-Only Cache Group

With the active standby pair replication scheme, you can choose to replicate any read-only cache groups. You can create the cache groups on the active master either before or after the active standby pair replication scheme is created.

Before the creation of active standby pair: You can create cache groups on the active master before the active standby pair replication scheme is created. Then, create the active standby pair replication scheme and perform a distribution to include the cache groups. See Creating a Read-Only Cache Group to Include Within a New Active Standby Pair.
After creation of active standby pair: You can create cache groups on the active master after the active standby pair replication scheme is created. See Making Other Changes to an Active Standby Pair.

Either way, cache groups are added to the active standby pair replication scheme after you perform a distribution to include these cache groups.

Creating a Read-Only Cache Group to Include Within a New Active Standby Pair

You can set up an active standby pair that replicates cache tables in a read-only cache group.

Before you create a database, see the information in these sections:

To set up an active standby pair that replicates a local read-only cache group, complete the following tasks:

Create a cache administration user in the Oracle database. See Create Users in the Oracle Database in Oracle TimesTen In-Memory Database Cache Guide.
Create a database. See Create a DSN for the TimesTen Database in Oracle TimesTen In-Memory Database Cache Guide.
Set the cache administration user ID and password by calling the ttCacheUidPwdSet built-in procedure. See Set the Cache Administration User Name and Password in the TimesTen Database in Oracle TimesTen In-Memory Database Cache Guide. For example:
```
call ttCacheUidPwdSet('cacheadmin','orapwd');
```
Start the cache agent on the database. Use the ttCacheStart built-in procedure or the ttAdmin -cachestart utility.
```
call ttCacheStart;
```

Use the CREATE CACHE GROUP statement to create the read-only cache group. For example:

CREATE READONLY CACHE GROUP customer_orders
        AUTOREFRESH INTERVAL 5 SECONDS
        FROM sales.customer
        (cust_num NUMBER(6) NOT NULL,
         region VARCHAR2(10),
         name VARCHAR2(50),
         address VARCHAR2(100),
         PRIMARY KEY(cust_num)),
        sales.orders
        (ord_num NUMBER(10) NOT NULL,
         cust_num NUMBER(6) NOT NULL,
         when_placed DATE NOT NULL,
         when_shipped DATE NOT NULL,
         PRIMARY KEY(ord_num),
         FOREIGN KEY(cust_num) REFERENCES sales.customer(cust_num));

Ensure that the autorefresh state is set to PAUSED. The autorefresh state is PAUSED by default after cache group creation. You can verify the autorefresh state by running the ttIsql cachegroups command:
```
cachegroups;
```
Create the replication scheme using the CREATE ACTIVE STANDBY PAIR statement.
For example, suppose master1 and master2 are defined as the master databases. sub1 and sub2 are defined as the subscriber databases. The databases reside on node1, node2, node3, and node4. The return service is RETURN RECEIPT. The replication scheme can be specified as follows:
```
CREATE ACTIVE STANDBY PAIR master1 ON "node1", master2 ON "node2"
        RETURN RECEIPT
        SUBSCRIBER sub1 ON "node3", sub2 ON "node4"
        STORE master1 ON "node1" PORT 21000 TIMEOUT 30
        STORE master2 ON "node2" PORT 20000 TIMEOUT 30;
```
Set the replication state to ACTIVE by calling the ttRepStateSet built-in procedure on the active database (master1). For example:
```
call ttRepStateSet('ACTIVE');
```
Set up the replication agent policy for master1 and start the replication agent. See Starting and Stopping the Replication Agents.
Load the cache group by using the LOAD CACHE GROUP statement. This starts the autorefresh process. For example:
```
LOAD CACHE GROUP customer_orders COMMIT EVERY 256 ROWS;
```
As the instance administrator, duplicate the active database (master1) to the standby database (master2). Use the ttRepAdmin -duplicate utility with the -keepCG option to preserve the cache group. Alternatively, you can use the ttRepDuplicateEx C function to duplicate the database. See Duplicating a Database. ttRepAdmin prompts for the values of -uid, -pwd, -cacheuid and -cachepwd.
```
ttRepAdmin -duplicate -from master1 -host node1 -keepCG 
 -connStr "DSN=master2;UID=;PWD="
```
Set up the replication agent policy on master2 and start the replication agent. See Starting and Stopping the Replication Agents.
The standby database enters the STANDBY state automatically. Wait for master2 to enter the STANDBY state. Call the ttRepStateGet built-in procedure to check the state of master2. For example:
```
call ttRepStateGet;
```
Start the cache agent for master2 using the ttCacheStart built-in procedure or the ttAdmin -cacheStart utility. For example:
```
call ttCacheStart;
```
As the instance administrator, duplicate the subscribers (sub1 and sub2) from the standby database (master2). Use the -noKeepCG command line option with ttRepAdmin -duplicate to convert the cache tables to normal TimesTen tables on the subscribers. ttRepAdmin prompts for the values of -uid and -pwd. See Duplicating a Database. For example:
```
ttRepAdmin -duplicate -from master2 -host node2 -nokeepCG
 -connStr "DSN=sub1;UID=;PWD="
```
Set up the replication agent policy on the subscribers and start the replication agent on each of the subscriber databases. See Starting and Stopping the Replication Agents.