Cache Groups and Replication
A cache group is a group of tables stored in a central Oracle database that are cached in local cache tables on TimesTen. Cache groups can be replicated between TimesTen databases. You can achieve high availability by using an active standby pair to replicate AWT or read-only cache groups.
This section describes the following ways to replicate cache groups:
Replicating an AWT Cache Group
An asynchronous writethrough (AWT) cache group can be configured as part of an active standby pair with optional read-only subscribers to ensure high availability and to distribute the application workload.
Figure 1-12 shows this configuration.
Figure 1-12 AWT Cache Group Replicated by an Active Standby Pair
Description of "Figure 1-12 AWT Cache Group Replicated by an Active Standby Pair"
Application updates are made to the active database, the updates are replicated to the standby database, and then the updates are asynchronously written to the Oracle database by the standby. At the same time, the updates are also replicated from the standby to the read-only subscribers, which may be used to distribute the load from reading applications. The tables on the read-only subscribers are not in cache groups.
When there is no standby database, the active database both accepts application updates and writes the updates asynchronously to the Oracle database and the read-only subscribers. This situation can occur when the standby has not yet been created, or when the active fails and the standby becomes the new active. TimesTen Classic reconfigures the AWT cache group when the standby becomes the new active.
If a failure occurs on the node where the active database resides, the standby master becomes the new active master. TimesTen Classic automatically reconfigures the AWT cache group so that it can be updated directly by the application and continue to propagate the updates to the Oracle database asynchronously.
See Setting Up an Active Standby Pair with an AWT Cache Group.
Replicating an AWT Cache Group With a Subscriber Propagating to an Oracle Database
You can recover from a complete failure of a site by creating a special disaster recovery read-only subscriber on a remote site as part of the active standby pair replication configuration.
Figure 1-13 shows this configuration.
Figure 1-13 Disaster Recovery Configuration With Active Standby Pair
Description of "Figure 1-13 Disaster Recovery Configuration With Active Standby Pair"
The standby database sends updates to cache group tables on the read-only subscriber. This special subscriber is located at a remote disaster recovery site and can propagate updates to a second Oracle database, also located at the disaster recovery site. You can set up more than one disaster recovery site with read-only subscribers and Oracle databases. See Using a Disaster Recovery Subscriber in an Active Standby Pair.
Replicating a Read-Only Cache Group
A read-only cache group enforces caching behavior in which committed updates on the Oracle database tables are automatically refreshed to the corresponding cache tables on TimesTen.
Figure 1-14 shows a read-only cache group replicated by an active standby pair.
Figure 1-14 Read-Only Cache Group Replicated by an Active Standby Pair
Description of "Figure 1-14 Read-Only Cache Group Replicated by an Active Standby Pair"
When the read-only cache group is replicated by an active standby pair, the cache
group on the active database is autorefreshed from the Oracle database and replicates
the updates to the standby, where AUTOREFRESH is also configured on the
cache group but is in the PAUSED state. In the event of a failure of
the active, TimesTen Classic automatically reconfigures the standby to be autorefreshed
when it takes over for the failed master database by setting the AUTOREFRESH
STATE to ON. TimesTen Classic also tracks whether updates
that have been autorefreshed from the Oracle database to the active database have been
replicated to the standby. This ensures that the autorefresh process picks up from the
correct point after the active fails, and no autorefreshed updates are lost.This
configuration may also include read-only subscriber databases. This enables the read
workload to be distributed across many databases. The cache groups on the standby
database replicate to regular (non-cache) tables on the subscribers. See Setting Up an Active Standby Pair with a Read-Only Cache Group.