Data Replication Within TimesTen Classic
The fundamental motivation behind data replication in TimesTen Classic is to make data highly available to applications with minimal performance impact. In addition to its role in failure recovery, replication is also useful for distributing application workloads across multiple databases for maximum performance and for facilitating online upgrades and maintenance.
Replication is the process of copying data from a master database to a subscriber database. Replication at each master and subscriber database is controlled by replication agents that communicate through TCP/IP stream sockets. The replication agent on the master database reads the records from the transaction log for the master database. It forwards changes to replicated elements to the replication agent on the subscriber database. The replication agent on the subscriber then applies the updates to its database. If the subscriber agent is not running when the updates are forwarded by the master, the master retains the updates in its transaction log until they can be applied at the subscriber.
You can increase replication throughput by configuring parallel replication at database creation time. You configure the number of threads for applying updates to subscribers. The updates are transmitted in commit order. See Configuring Automatic Parallel Replication in the Oracle TimesTen In-Memory Database Replication Guide.
TimesTen recommends the active standby pair configuration for highest availability. It is the only replication configuration that you can use for replicating cache groups.
Note:
For more information about replication, see Overview of TimesTen Replication in the Oracle TimesTen In-Memory Database Replication Guide.
The rest of this section includes the following topics:
Active Standby Pair
An active standby pair includes an active database, a standby database, optional read-only subscriber databases, and the tables and cache groups that comprise the databases.
Figure 6-1 shows an active standby pair.
In an active standby pair, two databases are defined as masters. One is an active database, and the other is a standby database. The active database is updated directly. The standby database cannot be updated directly. It receives the updates from the active database and propagates the changes to read-only subscribers. This arrangement ensures that the standby database is always ahead of the read-only subscribers and enables rapid failover to the standby database if the active database fails.
Only one of the master databases can function as an active database at a specific time. If the active database fails, the role of the standby database must be changed to active before recovering the failed database as a standby database. The replication agent must be started on the new standby database.
If the standby database fails, the active database replicates changes directly to the read-only subscribers. After the standby database has recovered, it contacts the active database to receive any updates that have been sent to the read-only subscribers while the standby was down or was recovering. When the active and the standby databases have been synchronized, then the standby resumes propagating changes to the subscribers.
Active standby replication can be used with cache to achieve cross-tier high availability. Active standby replication is available for both read-only and asynchronous writethrough cache groups. When used with read-only cache groups, updates are sent from the Oracle database to the active database. Thus, the Oracle database plays the role of the application in this configuration. When used with asynchronous writethrough cache groups, the standby database propagates updates that it receives from the active database to the Oracle database. In this scenario, the Oracle database plays the role of one of the read-only subscribers.
An active standby pair that replicates one of these types of cache groups can perform failover and recovery automatically with minimal chance of data loss. See Replicating Cache Groups Within Active Standby Pairs in Oracle TimesTen In-Memory Database Replication Guide.
Classic Replication Configurations
TimesTen replication architecture is flexible enough to achieve balance between performance and availability.
In general, classic replication can be configured to be:
- Unidirectional Replication: Unidirectional from a master to one or more subscribers.
-
Bidirectional Replication: Bidirectional between two or more databases that serve as both master and subscriber.
Unidirectional Replication
In a uidirectional replication scheme, the application is configured on both hosts so that the subscriber is ready to take over if the master host fails.
Figure 6-2 shows a unidirectional replication scheme.
While the master is up, updates from the application to the master database are replicated to the subscriber database. The application on the subscriber host does not run any updates against the subscriber database, but may read from that database. If the master fails, the application on the subscriber host takes over the update function and starts updating the subscriber database.
Figure 6-2 Unidirectional Replication Scheme
Description of "Figure 6-2 Unidirectional Replication Scheme"
Replication can also be used to copy updates from a master database to many subscriber databases. Figure 6-3 shows a replication scheme with multiple subscribers.
Figure 6-3 Unidirectional Replication to Multiple Subscribers
Description of "Figure 6-3 Unidirectional Replication to Multiple Subscribers"
Figure 6-4 shows a propagation configuration. One master copies updates to three subscriber nodes, which act as propagator nodes to forward those same updates to additional subscribers.
Bidirectional Replication
Bidirectional replication schemes are used for load balancing. The workload can be split between two bidirectionally replicated databases.
There are two basic types of load-balancing configurations:
-
Split workload where each database bidirectionally replicates a portion of its data to the other database. Figure 6-5 shows a split workload configuration.
-
Distributed workload where user access is distributed across duplicate application/database combinations that replicate updates to each other. In a distributed workload configuration, the application has the responsibility to divide the work between the two systems so that replication collisions do not occur. If collisions do occur, TimesTen has a timestamp-based collision detection and resolution capability. Figure 6-6 shows a distributed workload configuration.
Figure 6-6 Distributed Workload Replication
Description of "Figure 6-6 Distributed Workload Replication"
Asynchronous and Return Service Replication
TimesTen replication is asynchronous by default. When using asynchronous replication, an application updates the master database and continues working without waiting for the updates to be received by the subscribers.
The master and subscriber databases have internal mechanisms to confirm that the updates have been successfully received and committed by the subscriber. These mechanisms ensure that updates are applied at a subscriber only once, but they are invisible to the application.
Asynchronous replication provides maximum performance, but the application is completely decoupled from the receipt process of the replicated elements on the subscriber. TimesTen also provides two return service options for applications that need higher levels of confidence that the replicated data is consistent between the master and subscriber databases:
-
The return receipt service synchronizes the application with the replication mechanism by blocking the application until replication confirms that the update has been received by the subscriber replication agent.
-
The return twosafe service enables fully synchronous replication by blocking the application until replication confirms that the update has been both received and committed on the subscriber.
Note:
Do not use the return twosafe service with bidirectional replication. This can cause deadlocks.
Applications that use the return services trade some performance to ensure higher levels of consistency and reduce the risk of transaction loss between the master and subscriber databases. In the event of a master failure, the application has a higher degree of confidence that a transaction committed at the master persists in the subscribing database. Return receipt replication has less performance impact than return twosafe at the expense of potential loss of transactions.
Replication Failover and Recovery
For replication to make data highly available to applications with minimal performance impact, there must be a way to shift applications from the failed database to its backup as seamlessly as possible.
You can use Oracle Clusterware with TimesTen Classic to manage failures automatically in systems with active standby pairs. Other kinds of replication schemes can be managed with custom and third-party cluster managers. They detect failures, redirect users or applications from the failed database to either a standby database or a subscriber, and manage recovery of the failed database. The cluster manager or administrator can use TimesTen-provided utilities and functions to duplicate the existing database and recover the failed database.
Subscriber failures generally have no impact on the applications connected to the master databases and can be recovered without disrupting user service. If a failure occurs on a master database, the cluster manager must redirect the application load to a standby database or a subscriber in order to continue service with no or minimal interruption.
Automatic Client Failover for Active Standby Pair Replication
You can configure automatic client failover for TimesTen Classic databases that have active standby pairs with client/server connections. This enables the client to fail over automatically to the server on which the standby database resides.
See Using Automatic Client Failover in the Oracle TimesTen In-Memory Database Operations Guide.