Overview of Recovery Appliance Replication

In the example Figure 14-1, a protected database sends backups to one Recovery Appliance, which transfers the backups on to another Recovery Appliance. This topology is called one-way Recovery Appliance replication. The first Recovery Appliance is the upstream Recovery Appliance and the second is the downstream Recovery Appliance.

Figure 14-1 Simple Replication Topology

Description of Figure 14-1 follows
Description of "Figure 14-1 Simple Replication Topology"

Many other replication scenarios are possible, as given in Additonal Replication Topology Examples

Protection Policies for Replication

Replication for a protected database occurs when the following conditions are met:

  • On the upstream Recovery Appliance, a replication server configuration specifies a Recovery Appliance acting as a downstream replication Recovery Appliance (CREATE_REPLICATION_SERVER).

  • On the upstream Recovery Appliance, a protection policy is associated with the replication server configuration (ADD_REPLICATION_SERVER).

  • On the upstream Recovery Appliance, a protected database is assigned (ADD_DB) to the protection policy associated with the replication server configuration.

  • On the downstream Recovery Appliance, creating the protection policy (CREATE_PROTECTION_POLICY), adding the databases to the policy (ADD_DB), and granting replication acess to the database (GRANT_DB) should be done first in the overall setup.

By default, after performing ADD_REPLICATION_SERVER, the latest full backup is replicated for each database in the policy. If COPYALL_BACKUP is set to TRUE, all backups (fulls, incrementals, archived logs) are replicated. This replication mode can be used as part of migrating backups from one appliance to another. Thereafter, the upstream Recovery Appliance replicates new backups as it receives them.

How Recovery Appliance Replicates Backups: Basic Process

Assume that a protected database backs up to a Recovery Appliance using the incremental-forever policy. When an protected database sends a backup to a Recovery Appliance configured for replication, the following basic steps occur:

  1. The upstream Recovery Appliance ingests the backup, checking the protection policy to determine whether it is associated with a replication server configuration.

  2. If a replication server configuration exists for the protection policy, then the upstream Recovery Appliance replicates the backup. The replication process includes:

    • Creating metadata records to track the replicated records

      Note:

      When real-time redo transport is enabled, incoming redo changes are not replicated in real time by Recovery Appliance. When an archived redo log backup is created, the Recovery Appliance automatically replicates this backup along with the data file backups.

    • Transferring the data blocks over the network to each specified downstream Recovery Appliance

  3. The downstream Recovery Appliance ingests the backup, creating a virtual backup.

    Note:

    The ingest phase on the downstream is the same as the ingest phase described in Step 1. Thus, if the downstream Recovery Appliance is also configured to replicate the backup, then it assumes the role of an upstream Recovery Appliance, and then replicates the backup to the Recovery Appliances that are directly downstream, and so on.

  4. Shortly afterward, the upstream Recovery Appliance sends a reconcile request to the downstream Recovery Appliance, which in turn sends metadata about the backup to the upstream Recovery Appliance.

    In Recovery Appliance replication, reconciling is the process by which a Recovery Appliance receives metadata from the Recovery Appliances that are immediately downstream.

Thus, after the backup is replicated, both the upstream and downstream recovery catalog have a record of the protected database backup.

Archived Backup Mirroring

Archived backups mirroring (SBT mirroring) allows a downstream Recovery Appliance configured as a replication partner to access externally stored backups on tape, cloud or third party storage that were created by an upstream Recovery Appliance.

The local SBT library is configured by RACLI, or a system administrator, to access the same external storage, even if the external storage wasn't orginally set up with the remote Recovery Appliance.

Prior to RA 23.1, a downstream Recovery Appliance has a copy of the backups and catalog records for the upstream Recovery Appliance, but has no information or access to the archived backups on external storage. Using archived backups mirroring starting in RA 23.1, the remote Recovery Appliance has details about this backup from the source replicated Recovery Appliance.

Copy-to-tape and archived-to-cloud backup records are mirrored between the Recovery Appliance catalogs in a replication pair, so that either Recovery Appliance can access backups from tape/cloud that are needed for restore operations. This is enabled by setting sbt_mirroring=>'TRUE' in the SBT library configured for tape/cloud with the same SBT library name on each Recovery Appliance.

Note:

The user must assure that both Recovery Appliances point to the same external storage before enabling.

The local SBT library is linked with the replicated backup piece using the SBT library mapping. This allows externally stored replication backup-pieces to be locally available for restore operations.

CREATE_SBT_LIBRARY and UPDATE_SBT_LIBRARY help identify the library metadata (SBT_LIB_DESC) with a new column sbt_mirror. If the library has been marked to be mirrored but there is no corresponding partner on the other Recovery Appliance then, there won’t be any library information exchange during reconcile and everything proceeds as before.

Requirements

  • The SBT library be setup on a remote Recovery Appliance such that the remote SBT library has the same name and accesses the same external storage destination as its partner Recovery Appliance.
  • The same library name is used across the replicating pair of Recovery Appliance. The library name on a Recovery Appliance is always unique, so this uniqueness along with library type and replication pair details help map the SBT libraries across Recovery Appliances. The library type can be "T" (tape) or "C" (cloud).
  • The SBT mirror can be setup without automation with the API. For migration scenarios between Recovery Appliance's, RACLI migration automates the setup of all configurations needed on the destination Recovery Appliance, including the SBT libraries.
  • The automation layer is also required to check whether there are any library name conflicts on paired Recovery Appliance before doing the setup

Using SBT Mirroring

All the metadata mapping between the partner Recovery Appliances is done via reconcile. This synchronizes the catalog metadata between the replicating parnter Recovery Appliances and allows the upstream Recovery Appliance to access the downstream backup metadata.

After setting up mirroring, it won't take effect instantly. A reconcile and/or next backup, which would ultimately initiate an implicit reconcile, make the changes.

  1. User calls CREATE_SBT_LIBRARY or UPDATE_SBT_LIBRARY with sbt_mirror set to YES. This calls the required setup automation.

  2. The triggered automation looks at the associated replicating Recovery Appliance and initiates a SBT library creation with library name and type specifications mentioned above.

  3. On the paired Recovery Appliance, the automation makes sure there does not already exist any SBT library with same name.

  4. The automation layer creates a new SBT library (with sbt_mirror set to YES) on the partner Recovery Appliance that can access the same external storage location as the Recovery Appliance initiating this automation (keeping the library name same).

How RMAN Restores Backups in a Replication Environment

To restore a protected database, RMAN typically connects AS CATALOG to the same Recovery Appliance to which it originally sent backups. For example, in Figure 14-2, if RMAN needed to restore orcl11, then RMAN would connect to the catalog on the upstream Recovery Appliance.

If backups exist on any Recovery Appliances in the replication scheme, then the upstream Recovery Appliance can retrieve and restore the backups from the other Recovery Appliances. For example, in Figure 14-2, if RMAN needed to restore orcl11, if the backups from the upstream had been purged, and if the backups were still available on the downstream Recovery Appliance, then those backups are transferred to the upstream Recovery Appliance and then to the database.

If necessary, RMAN can also restore a backup directly from a downstream Recovery Appliance. RMAN connects AS CATALOG to the downstream Recovery Appliance, and then restores the backup. For example, in Figure 14-2, if RMAN needed to restore prod3, but the upstream Recovery Appliance was temporarily inaccessible, then RMAN could connect directly to the catalog on the downstream Recovery Appliance, and then restore the backups directly to the protected database host.

Note:

When using either Oracle Enterprise Manager Cloud Control (Cloud Control) or the command line, restoring backups from a downstream Recovery Appliance requires additional configuration. See Zero Data Loss Recovery Appliance Protected Database Configuration Guide.