After a demanding amount of development and testing over the past several months, I couldn’t be more excited to announce the feature that completes our Autonomous Database (ADB) disaster recovery story – Cross-Region Autonomous Data Guard (X-ADG)! I couldn’t be more excited to announce the feature that tells the other half our Autonomous Database disaster recovery story – Cross-Region Autonomous Data Guard (X-ADG)!
Last year, when I announced Autonomous Data Guard on ADB Serverless (ADB-S), with no more effort than a few clicks you were able to protect your database instance against local outages, with a standby database running in the same region as its source.
Beginning today, with similar ease of use, you will be able to protect your database instance from true disaster, complete region failure type scenarios (earthquakes, fires, floods etc.) with a standby database running in a different (ie. remote) region than the source, primary database.
As in my first post, before we dive into the how-to-use, let us first understand the following disaster recovery terminology as it relates to cross-region ADG:
Peer Databases: Two or more databases that are peered (linked and replicated) between each other. They consist of a Primary database and Standby (copy of the primary) databases.
Primary or Source Database: The main database that is actively being used to read from and write to by a user or application.
Standby Database: A replica of the primary database which is constantly and passively refreshing (ie. replicating) data from the primary. This standby database is used in case of failure of the primary. The standby may be provisioned in a remote region (a remote standby), or a local region (a local standby).
Primary Region: The region in which a user first provisions a primary database and enables cross-region Autonomous Data Guard on it.
Remote Region: The user-selected region in which to provision the standby from a database instance while enabling cross-region Autonomous Data Guard.
Paired or Buddy Regions: Two regions that are paired together to support X-ADG, such that a primary database may be provisioned in one of the regions and its remote standby may be provisioned in the other region. Paired regions will show up in the list of regions when enabling X-ADG as long you are subscribed to the necessary region. If you do not see your preferred, subscribed region in the remote region selection dropdown, you may file a service request and have Oracle pair the required regions for you.
Recovery Point Objective (RPO): An organization’s tolerance for data loss, after which business operations start to get severely impacted, usually expressed in minutes. We want this to be as low as possible.
Recovery Time Object (RTO): An organization’s tolerance for the unavailability (or downtime) of a service after which business operations start to get severely impacted, usually expressed in minutes. We want this to be as low as possible.
With our memory refreshed, let’s now have a look at setting up your new cross-region Autonomous Data Guard standby instance.
Enable cross-region Autonomous Data Guard by provisioning a remote standby instance
Navigate to your Oracle
Failover across regions to the remote standby
Switchover across regions to the remote standby
For details on how of X-ADG is billed you may refer to the documentation and PaaS & IaaS Service Description