Describes
cross-region operations with Backup-Based Disaster
Recovery.
Add a Cross-Region Disaster Recovery Peer In addition to a local Backup-Based Disaster Recovery peer, you can add one or more remote region (cross-region) Backup-Based Disaster Recovery peers.
In addition
to a local Backup-Based Disaster
Recovery
peer, you can add one or more remote region (cross-region) Backup-Based Disaster
Recovery
peers.
Perform the following prerequisite steps as necessary:
Open the Oracle Cloud
Infrastructure Console by clicking the next to Oracle Cloud.
From the Oracle
Cloud Infrastructure left navigation menu click
Oracle Database and then,
depending on your workload click one of: Autonomous Data
Warehouse,
Autonomous JSON Database, or Autonomous Transaction
Processing.
On the Autonomous
Databases page select your Autonomous Database from the links under the
Display name
column.
To add a cross-region Backup-Based Disaster
Recovery peer, do the following:
On the Autonomous Database Details
page, under Disaster recovery, in the
Cross-region field, click Add peer
database, alternatively in the Resources
area click Disaster recovery.
The region list shows the available remote regions where you can
create a cross-region peer. When you add a peer database, the list of
available regions only shows a remote region if your tenancy is subscribed
to the remote region (you must be subscribed to the paired remote region).
See Autonomous Database Cross-Region Paired Regions for more information.
In the Select a compartment drop-down list, select a
compartment.
Select the disaster recovery type. In addition, when the source database is
configured with a private endpoint, enter the private endpoint information for
the peer.
Select the disaster recovery type: Backup-based disaster recovery.
In these Network access for standby fields you specify the private endpoint's VCN and Subnet on the remote region where the standby is created. Configure Private Endpoints.
Note
If you change your
network access on the source database to enable a private endpoint
after the standby is created, you must manually access the standby
to enable a private endpoint on the peer.
Click Add peer database.
The Autonomous Database
Lifecycle state changes to Updating. In the
Resources area, the number next to
Disaster recovery increments to show that you
have another disaster recovery peer, and the State
field shows Provisioning for the new cross-region
peer.
Note
While you add a new peer,
the primary database is available for read/write operations. There is no
downtime on the primary database.
Autonomous Database generates a
work request when you add a cross-region peer To view the work request,
under Resources click Work
Requests.
If cross-region backup replication is disabled, select
Enable cross-region backup replication to disaster
recovery peer to enable the option.
If cross-region backup replication is enabled, deselect
Enable cross-region backup replication to disaster
recovery peer to disable the option.
Click Submit.
The Autonomous Database Lifecycle state
changes to Updating.
If you select Enable cross-region backup replication to disaster recovery
peer, it can take between several minutes and several hours to
replicate the backups to the remote region, depending on the size of the backups.
After backups are replicated, when you select Backups under
Resources on the peer database's Oracle Cloud
Infrastructure Console, you will see the list of replicated backups.
Convert Cross-Region Backup-Based Disaster
Recovery Peer to
Snapshot Standby
🔗
A
cross-region Backup-Based Disaster
Recovery
peer can be converted to a snapshot standby. This converts the peer to a read-write database
for up to two days.
Disconnect a Cross-Region Backup-Based Disaster
Recovery
Peer
🔗
Shows
you the steps to disconnect a cross-region Backup-Based Disaster
Recovery peer from the Primary database.
Note
The disconnect operation for a
cross-region Backup-Based Disaster
Recovery peer can only be performed on an Autonomous Database instance that uses the
ECPU compute model.
When you disconnect a cross-region peer, the peer database is
disassociated from the primary database. This converts the database from a peer
database to a standalone database. Following the disconnect operation you are not
allowed to reconnect to the Primary.
The steps to disconnect a Backup-Based Disaster
Recovery peer standby are the same as those to
disconnect a standby database. See Disconnect a Peer Database for more information.
Notes for disconnecting a remote peer.
The disconnect operation for a remote peer can only be performed
on an Autonomous Database instance
that uses the ECPU compute model.
After the disconnect operation, the standalone database is no
longer associated with the database that was the Primary database. To use
the database as a standalone database, you must know the name of the
database that was disconnected from the Primary database.
There is no reconnect operation. After you disconnect a snapshot
standby you are not allowed to reconnect to the Primary.
After the disconnect operation, the standalone database is no
longer associated with the database that was the Primary database. To use
the database as a standalone database, you must know the name of the
database that was disconnected from the Primary database.
After the disconnect operation, the standalone database starts
taking new backups as a standalone database.
Describes
the steps to terminate a cross-region (remote) peer.
Perform the following prerequisite steps as necessary:
Open the Oracle Cloud
Infrastructure Console by clicking the next to Oracle Cloud.
From the Oracle
Cloud Infrastructure left navigation menu click
Oracle Database and then,
depending on your workload click one of: Autonomous Data
Warehouse,
Autonomous JSON Database, or Autonomous Transaction
Processing.
On the Autonomous
Databases page select your Autonomous Database from the links under the
Display name
column.
To terminate a cross-region (remote) peer:
On the Primary database, on the Autonomous Database Details page under Resources, select Disaster recovery.
Access the Oracle Cloud
Infrastructure Console for the remote region peer.
The Disaster recovery information area
shows the Peer Autonomous Database. The remote peer
has the same display name as the primary database, with an
"_region" extension. Where region is the
region name, such as IAD or BOM.
If you created the cross-region peer before the introduction of
support for multiple cross-region peers, the remote peer has the same
display name as the primary database, with an "_Remote"
extension.
Under Peer Autonomous Database, click the
link for the remote peer to access the cross-region peer.
On the Oracle Cloud
Infrastructure Console for the remote peer, on the Details page, from
the More actions drop-down
list, select Terminate.
On the Terminate Autonomous Database page, enter the
database name to confirm that you want to terminate the cross-region peer.
Click Terminate Autonomous Database.
While the peer is terminating, the Lifecycle state changes to
Terminating.
There are limitations for disabling when an instance has a cross-region Backup-Based Disaster
Recovery
peer, as follows:
A peer in the remote region cannot be disabled from the primary database.
When Backup-Based Disaster
Recovery
is enabled with a cross-region peer, you must terminate all cross-region
disaster recovery peers before you terminate the primary role database. If
you attempt to terminate the primary, the system gives you an error.
In this case, after you terminate all cross-region (remote) peers, you can terminate
the primary database.
Update Remote Peer Network ACLs for a Backup-Based Disaster
Recovery
Peer
🔗
You can independently modify network ACLs on a
remote disaster recovery peer database.
By default the disaster recovery primary and remote peer
databases use the same network Access Control Lists (ACLs).
Optionally, you can configure ACLs independently on remote peer
databases. This provides an option to use different ACLs on remote
peer databases.
If you modify the ACLs on a remote peer, Autonomous Database no
longer keeps the ACL configuration synchronized between the primary
and the remote peer. After you modify the ACLs on a remote peer,
Autonomous Database manages the ACLs on the remote peer
independently.
To use different network ACLs on a remote Autonomous Database
peer:
On the primary database, on the Autonomous Database Details page, under
Resources select
Disaster recovery.
Access the remote peer.
The Disaster recovery
information area shows the Peer
Autonomous Database. The remote peer
database by default has the same display name as the
primary database, with an extension. For example,
DBNAME_remote.
Under Peer Autonomous
Database, click the link to access a
cross-region peer.
On the remote peer database, edit the access control
list.
Before you change ACL the dialog
shows a message indicating that ACLs on the peer
database are syncing from the Primary database. For
example:
Notes for Cross-Region Backup-Based Disaster
Recovery Peer
Operations
🔗
Lists notes
and restrictions for adding and managing a cross-region Backup-Based Disaster
Recovery
peer.
After you add a cross-region (remote) peer, the wallet and
connection string from the primary database will contain only the hostname of
the primary database, and the wallet and connection string from the remote
database will contain only the hostname of the remote database. This applies to
both instance and regional wallets.
If you enable the option Enable cross-region backup
replication to disaster recovery peer, it can take between
several minutes and several hours to replicate the backups to the remote region,
depending on the size of the backups. After backups are replicated, when you
select Backups under Resources on
the peer database's Oracle Cloud
Infrastructure Console, you will see the list of replicated backups.
When you add a cross region peer there are special considerations
when the primary instance is using customer-managed keys, or if you want to
switch to use customer-managed keys. See Autonomous Data Guard with Customer Managed Keys for more information.
When you add a Backup-Based Disaster
Recovery peer, while the Lifecycle
state field shows Updating, the following
actions are disabled on the Primary database: