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.
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".
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.
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:
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
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!
Nilay is a principal product manager at Oracle, responsible for adoption and feature development of Oracle's flagship converged cloud database - Autonomous Database. He was previously a developer and data scientist, and has a decade worth of experience in data warehousing, dimensional modeling, search engines and machine learning. A global Carnegie Mellon graduate, he has had the opportunity to work, travel and study in several different countries in various fields. His avocation is music; in his downtime he enjoys playing guitar or piano with a strong cup of chai nearby.
Nilay blogs regularly, and often speaks at cloud and database events. Follow his work on the Twitter @theproductlad