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)! 

Last year, I announced local Autonomous Data Guard on ADB on Serverless (ADB-S), with which you were able to protect your database instance against local outages, using a standby database running in the same region as its source, with no more effort than a few clicks.

Beginning today, with the same ease of use in X-ADG, 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 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. The list of paired regions for X-ADG follows the precedent set by OCI for the Block Volume service replication regions as documented here.

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.

Enable cross-region Autonomous Data Guard by provisioning a remote standby instance

Navigate to your Oracle Cloud Infrastructure (OCI) database console, click "Enable" under Autonomous Data Guard and select a remote region to create the standby. Each region has one or a few nearby "paired regions" in which a remote standby may be created. Make sure your tenancy is subscribed to the remote region in which you intend to create the standby.

Note: If you already have ADG enabled with a local standby, you may instead scroll to the Autonomous Data Guard details section at the bottom of the console page and click "Add Standby Database". We currently support enabling two standby databases, one local (same-region) and one remote (cross-region).

It's that simple - You will now see your cross-region standby instance provisioning in the remote region, in the new ADG tab at the bottom of the OCI DB console; once it becomes available, you are protected against regional outages.

You will notice that the remote standby is visible in the remote region with your source database's name trailed by "_Remote".

Failover across regions to the remote standby

If a regional failure occurs and your primary database is brought down, you may trigger a "Failover" from the remote standby database to which you want to failover. A failover is a role change, switching control from the primary database to the standby database (as long as the standby is Available). After a failover, a new remote standby for your new primary will be automatically provisioned, when the primary region becomes available again. 

During such a failover, the system automatically recovers as much data as possible minimizing any potential data loss; there may be a few seconds or minutes of data loss. You would usually perform a failover in a true disaster scenario, if a switchover has failed, accepting the few minutes of potential data loss to ensure getting your database back online as soon as possible.

For Cross-Region Autonomous Data Guard, the RTO is 15 minutes and RPO is 1 minute.

Switchover testing across regions with the remote standby

Once your remote standby is provisioned, you will see a "Switchover" option on your database's console. Clicking the Switchover button from the remote standby database, while both your primary and standby are healthy (ie. in the Available or Stopped states), performs a role change - Switching from the primary database to the remote standby database. This may take several minutes, depending on the amount of changes in the primary database. Switchover guarantees no data loss. You would usually perform a Switchover to test your applications or mid-tiers against this role change behaviour of the primary.

Here are some important additional points to note about cross-region Autonomous Data Guard:

• We do not support automatic failover across regions since failing over across regions is more impactful than failing over locally; often users want to failover mid-tiers / applications along with the database for optimum performance. You may manually trigger the switchover/failover button on the console or a scripted API call when required. For the same reason, if you have both a local and a remote standby database available, we always recommend failover to the local standby first.
• For best performance, we aim to minimize any dependencies or wait times between the primary and remote databases. Therefore triggering a failover/switchover across regions, with the button or API call, is done so directly on the database that is currently in standby mode (ie. not the primary database). In contrast, as the local standby is kept running in the background not visible as a separate database, switchover/failover to the local (same-region) standby database is triggered from the Primary database.
• After a switchover/failover to a remote region, the database wallet downloaded in the remote region should be used to connect to the database in the remote region.
• If you are connecting to a remote standby private endpoint enabled database across regions, from your application lying in the primary region VCN, you will need to set up remote VCN peering and domain forwarding between the two regions' VCNs. Refer to my follow-up post, diving into the networking setup required with PE here.
   

If you prefer to script your failover/switchover or other ADB calls, you may refer to the  Autonomous Database APIs. You may also subscribe to  Events to be notified of your standby's operations. Standby databases do incur additional costs. Learn all about standby databases by referring to the official documentation.

My hope is that every production database user out there takes advantage of this new Autonomous Data Guard feature to quickly and easily protect their databases from rare but potentially catastrophic failure scenarios. 

Like what I write? Follow me on the Twitter!