Types of Replication Schemes
You create a replication scheme to define a specific configuration of master and subscriber databases.
This section describes the possible relationships you can define between master and subscriber databases when creating a replication scheme.
When defining a relationship between a master and subscriber, consider these replication schemes:
Active Standby Pair With Read-Only Subscribers
You can create an active standby pair replication scheme with an active master, a standby master, and several read-only subscriber databases.
Figure 1-4 shows an active standby pair replication scheme with an active master, a standby master, and four read-only subscriber databases.
The active standby pair can replicate a whole database or select elements like tables and cache groups.
In an active standby pair, two databases are defined as master databases. One is an active master, and the other is a standby master. The application updates the active master directly. Applications cannot update the standby master. It receives the updates from the active master and propagates the changes to as many as 127 read-only subscriber databases. This arrangement ensures that the standby master is always ahead of the subscriber databases and enables rapid failover to the standby master if the active master fails.
Only one of the master databases can function as an active master at a specific time. You can manage failover and recovery of an active standby pair with Oracle Clusterware. See Using Oracle Clusterware to Manage Active Standby Pairs. You can also manage failover and recovery manually. See Administering an Active Standby Pair Without Cache Groups or Administering an Active Standby Pair With Cache Groups.
If the standby master fails, the active master can replicate changes directly to the read-only subscribers. After the standby database has been recovered, it contacts the active master to receive any updates that have been sent to the subscribers while the standby master was down or was recovering. When the active master and the standby master have been synchronized, then the standby master resumes propagating changes to the subscribers.
For details about setting up an active standby pair, see Defining an Active Standby Pair Replication Scheme, Setting Up an Active Standby Pair With No Cache Groups, Setting Up an Active Standby Pair with a Read-Only Cache Group, or Setting Up an Active Standby Pair with an AWT Cache Group.
Classic Replication
Classic replication schemes enable you to design relationships between masters and subscribers.
The following sections describe classic replication schemes:
Full Database Replication or Selective Replication
You can replicate a full master database or selectively replicate some elements in the master database to a subscriber database.
Figure 1-5 illustrates a full replication scheme in which the entire master database is replicated to the subscriber.
Figure 1-5 Replicating the Entire Master Database
You can also configure your master and subscriber databases to selectively replicate some elements in a master database to subscribers. Figure 1-6 shows examples of selective replication. The left side of the figure shows a master database that replicates the same selected elements to multiple subscribers, while the right side shows a master that replicates different elements to each subscriber.
Figure 1-6 Replicating Selected Elements to Multiple Subscribers
Description of "Figure 1-6 Replicating Selected Elements to Multiple Subscribers"
Unidirectional or Bidirectional Replication
Unidirectional replication consists of a master database that sends updates to one or more subscriber databases. Bidirectional replication consists of two databases that operate bidirectionally, where each database is both a master and a subscriber to each other.
These are basic ways to use bidirectional replication:
-
Split workload configuration: In a split workload configuration, each database serves as a master for some elements and a subscriber for others.
Consider the example shown in Figure 1-7, where the accounts for Chicago are processed on database A while the accounts for New York are processed on database B.
Figure 1-7 Split Workload Bidirectional Replication
Description of "Figure 1-7 Split Workload Bidirectional Replication" -
Distributed workload: In a distributed workload replication scheme, user access is distributed across duplicate application/database combinations that replicate any update on any element to each other. In the event of a failure, the affected users can be quickly shifted to any application/database combination.The distributed workload configuration is shown in Figure 1-8. Users access duplicate applications on each database, which serves as both master and subscriber for the other database.
Figure 1-8 Distributed Workload Configuration
Description of "Figure 1-8 Distributed Workload Configuration"When databases are replicated in a distributed workload configuration, it is possible for separate users to concurrently update the same rows and replicate the updates to one another. Your application should ensure that such conflicts cannot occur, that they be acceptable if they do occur, or that they can be successfully resolved using the conflict resolution mechanism described in Resolving Replication Conflicts.
Note:
Do not use a distributed workload configuration with the return twosafe return service.
Direct Replication or Propagation
You can define a subscriber to serve as a propagator that receives replicated updates from a master and passes them on to subscribers of its own.
Propagators are useful for optimizing replication performance over lower-bandwidth network connections, such as those between servers in an intranet. For example, consider the direct replication configuration illustrated in Figure 1-9, where a master directly replicates to four subscribers over an intranet connection. Replicating to each subscriber over a network connection in this manner is an inefficient use of network bandwidth.
Figure 1-9 Master Replicating Directly to Multiple Subscribers Over a Network
Description of "Figure 1-9 Master Replicating Directly to Multiple Subscribers Over a Network"
For optimum performance, consider the configuration shown in Figure 1-10, where the master replicates to a single propagator over the network connection. The propagator in turn forwards the updates to each subscriber on its local area network.
Figure 1-10 Master Replicating to a Single Propagator Over a Network
Description of "Figure 1-10 Master Replicating to a Single Propagator Over a Network"
Propagators are also useful for distributing replication loads in configurations that involve a master database that must replicate to a large number of subscribers. For example, it is more efficient for the master to replicate to three propagators, rather than directly to the 12 subscribers as shown in Figure 1-11.
Figure 1-11 Using Propagators to Replicate to Many Subscribers
Description of "Figure 1-11 Using Propagators to Replicate to Many Subscribers"
Note:
Each propagator is one-hop, which means that you can forward an update only once. You cannot have a hierarchy of propagators where propagators forward updates to other propagators.