Replication Topology Examples

Replication topologies can be as complex as required. The primary variables are as follows:

• The total number of Recovery Appliances in the replication environment, and their relationships to one another

• The protection policies (CREATE_PROTECTION_POLICY) on the upstream Recovery Appliance that manage the outgoing replicated backups, and the policies on the downstream Recovery Appliance that manage the incoming replicated backups

• The replication server configurations (CREATE_REPLICATION_SERVER) that exist on each Recovery Appliance in the replication environment

• The association between a replication server configuration and a protection policy (ADD_REPLICATION_SERVER)

You can chain replication so that an upstream Recovery Appliance replicates to multiple downstream Recovery Appliances, while a downstream Recovery Appliance receives backups from multiple upstream Recovery Appliances. A downstream Recovery Appliance can receive both backups from both its own protected databases and replicated backups. Any Recovery Appliance in the replication topology can simultaneously perform the upstream and downstream replication roles.

Note:

If a Recovery Appliance is both upstream and downstream, then you must configure it for both roles.

Replication to One Downstream Recovery Appliance

Figure 14-2 shows three databases associated with the reppolicy_us_bronze protection policy (orcl08, orcl09, and orcl10), and three databases associated with the reppolicy_us_gold protection policy (orcl11, orcl12, and orcl13). Only reppolicy_us_gold is associated with a replication server configuration, which is named us_bost_ds_desm. In this topology, the upstream ZDLRA Boston only transfers backups from databases protected by the reppolicy_us_gold policy to the downstream ZDLRA Des Moines.

Figure 14-2 Databases Replicating to One Recovery Appliance

Description of "Figure 14-2 Databases Replicating to One Recovery Appliance"

Replication to Multiple Downstream Recovery Appliances

Because each protected database has its own protection policy, each policy can be associated with a different replication server configuration. For example, in Figure 14-3, the reppolicy_us_bronze policy is associated with replication server configuration us_bost_ds_sf, which replicates backups for databases protected by reppolicy_us_bronze (orcl08, orcl09, and orcl10) to the downstream Recovery Appliance named ZDLRA San Francisco. The reppolicy_us_gold policy is associated with replication server configuration us_bost_ds_desm, which replicates backups for databases protected by reppolicy_us_gold (orcl11, orcl12, and orcl13) to the downstream Recovery Appliance named ZDLRA Des Moines.

Figure 14-3 Databases Replicated to Multiple Recovery Appliances

Description of "Figure 14-3 Databases Replicated to Multiple Recovery Appliances"

Replication Using Different Policies on Downstream Recovery Appliances

At each downstream Recovery Appliance in a replication scheme, the protection policy defines a disk recovery window goal and tape retention policy for received backups. The downstream configuration is completely independent of the upstream configuration. Thus, you have the flexibility to configure a downstream Recovery Appliance with more storage and longer recovery windows than its upstream Recovery Appliances, for example, using the downstream Recovery Appliance as a longer-term retention backup repository.

Figure 14-4 shows that reppolicy_us_bronze backups up on the upstream Recovery Appliance are protected by the reppolicy_ds_bronze policy on ZDLRA San Francisco. The reppolicy_us_gold backups up on the upstream Recovery Appliance are protected by the reppolicy_ds_gold policy on ZDLRA Des Moines.

Figure 14-4 Different Protection Policies on Each Recovery Appliance

Description of "Figure 14-4 Different Protection Policies on Each Recovery Appliance"

Cascaded Replication

Figure 14-5 shows a more complicated topology. Databases orcl11, orcl12, and orcl13 are protected by the reppolicy_us_gold protection policy on ZDLRA Boston, which is furthest upstream. The reppolicy_us_gold policy replicates the backups for these databases to ZDLRA Des Moines, which is immediately downstream. However, two separate protection policies exist on ZDLRA Des Moines: reppolicy_ds_gold1, which protects databases orcl11 and orcl12, and reppolicy_ds_gold2, which protects only database orcl13.

Figure 14-5 Cascaded Replication, with Different Protection Policies on Each Recovery Appliance

Description of "Figure 14-5 Cascaded Replication, with Different Protection Policies on Each Recovery Appliance"

In Figure 14-5, the reppolicy_ds_gold2 protection policy is associated with the replication server configuration us_desm_ds_la. ZDLRA Des Moines then replicates backups of orcl13, which is the only database protected by reppolicy_ds_gold2, to ZDLRA Los Angeles, which is the Recovery Appliance that is farthest downstream. The backups of orcl13 that reside on ZDLRA Los Angeles are protected by the reppolicy_dds_gold policy. This configuration, in which three or more Recovery Appliances are linked in a chain, is called cascaded replication.

Bi-Directional Replication between Recovery Appliances

Bi-directional replication, also known as "backup anywhere replication", allows two Recovery Appliances RA-x and RA-y to replicate between each other for the same (or different) protected databases. Thus, both Recovery Appliances have a full set of backups.

Description of the illustration rep_backupanywhere.png

Two Recovery Appliances RA-x and RA-y replicate between each other, and are the upstream and downstream of each other. Backups from protected databases DB-a and DB-b flow to their upstream Recovery Appliance, RA-x and RA-y respectively. New backups are replicated to the other (downstream) Recovery Appliance to synchronize the backup state across the Recovery Appliances.

For examples of how this works in a High Availability / Disaster Recovery (HADR) configuration, refer to Replication Mode for HADR.

Replication Request-Only Mode

Request-only mode replication is useful for planned maintenance and reduces the amount of database backups, redo logs, and archive logs that must be transmitted between Recovery Appliances to re-establish its full recoverability of its databases at the conclusion of maintenance.

In request_only mode replication, the upstream (RA-x) Recovery Appliance receives the primary database backups while the downstream (RA-y) receives the standby database backups, redo logs, and archive logs. When the upstream RA-x is offline for planned maintenance as one example, the primary database redo and archive logs are redirected to the downstream RA-y, where new archived log backups are created in order to preserve database recoverability.

RA-y is not affected by RA-x outage and still receives level 1 backups from standby database as normal. Standby backups on RA-y can be used for primary database restores. When RA-x comes back online, all previously redirected backups are replicated from the downstream RA-y to the upstream RA-x to re-establish its full recoverability of its databases.

Description of the illustration rep_request.png

Request mode can be thought of as "Read only replication with the ability to request backups that it missed while not running". Request mode is built on top of the technologies that enabled Backup Anywhere, but it is not Backup Anywhere.

Redo and archived logs are the more critical data to retrieve from the upstream databases, because the database can hang if the local archived log directory fills up. Therefore, they are transmitted to RA-y so that they can be safely deleted by RMAN on DB-a.

The command RMAN CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP 1 TIMES establishes that when redo has been shipped and backed up on RA-y, then RA-x can safely delete the local archived logs to reclaim space. With this policy configured, the command RMAN DELETE ARCHIVELOG can also be used to safely reclaim local archived log space.

Read-Only Replication between Recovery Appliances

The read_only replication mode is useful when changing the destination Recovery Appliance for database backups from the original RA-x to a different RA-y while backups remain available on RA-x to RA-y for restore operations as needed. A replication server for read_only mode can be configured in the protection policy for RA-y and designates RA-x as the downstream. All backups for the databases in the policy that exist on the downstream are retrievable when and if needed from the upstream. After the old backups on the original RA-x have expired according to the protection policy, RA-y will have no need for the backups on RA-x allowing RA-x to be transitioned out of the backup scenario.

Description of the illustration rep_readonly.png

The important use-case for read_only replication is when a different Recovery Appliance is to be used as the destination for database backups, such as when commissioning new Recovery Appliances in order to balance the load or to de-commission old Recovery Appliances. This allows for the graceful transfer of backup / restore between Recovery Appliances.

COPYALL Replication

The COPYALL mode is established in the protection policy and replicates literally all of the existing backups for the databases in that policy to a downstream Recovery Appliance. This includes backups that might be expired but not yet purged from the upstream Recovery Appliance.

On the upstream Recovery Appliance, backups are replicated in a controlled and ordered manner.

On the downstream Recovery Appliance, ingesting is COPYALL aware and does the right thing. Specifically, the backups are ingested in the correct order.

Backups can be sent to either the upstream or downstream during the COPYALL process.

On the downstream Recovery Appliance, a database can be a COPYALL destination only once.

The COPYALL mode is the basis for migration or moving of a database from one Recovery Appliance to another. The other replication modes can migrate a database to a new Recovery Appliance, but requires waiting for the full recovery window before any backup data can be deleted from the old Recovery Appliance. The COPYALL mode is used to force all data to the downstream Recovery Appliance now.