# Emulate Oracle DR by using a PostgreSQL-compatible Aurora global database
*HariKrishna Boorgadda, Amazon Web Services*
## Summary
Best practices for Enterprise disaster recovery (DR) basically consist of designing and implementing fault-tolerant hardware and software systems that can survive a disaster (*business continuance*) and resume normal operations (*business resumption*), with minimal intervention and, ideally, with no data loss. Building fault-tolerant environments to satisfy Enterprise DR objectives can be expensive and time consuming and requires a strong commitment by the business.
Oracle Database provides three different approaches to DR that provide the highest level of data protection and availability compared to any other approach for protecting Oracle data.
+ Oracle Zero Data Loss Recovery Appliance
+ Oracle Active Data Guard
+ Oracle GoldenGate
This pattern provides a way to emulate the Oracle GoldenGate DR by using an Amazon Aurora global database. The reference architecture uses Oracle GoldenGate for DR across three AWS Regions. The pattern walks through the replatforming of the source architecture to the cloud-native Aurora global database based on Amazon Aurora PostgreSQL–Compatible Edition.
Aurora global databases are designed for applications with a global footprint. A single Aurora database spans multiple AWS Regions with as many as five secondary Regions. Aurora global databases provide the following features:
+ Physical storage-level replication
+ Low-latency global reads
+ Fast disaster recovery from Region-wide outages
+ Fast cross-Region migrations
+ Low replication lag across Regions
+ Little-to-no performance impact on your database
For more information about Aurora global database features and advantages, see [Using Amazon Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database-overview). For more information about unplanned and managed failovers, see [Using failover in an Amazon Aurora global database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-failover).
## Prerequisites and limitations
**Prerequisites **
+ An active AWS account
+ A Java Database Connectivity (JDBC) PostgreSQL driver for application connectivity
+ An Aurora global database based on Amazon Aurora PostgreSQL-Compatible Edition
+ An Oracle Real Application Clusters (RAC) database migrated to the Aurora global database based on Aurora PostgreSQL–Compatible
**Limitations of Aurora global databases **
+ Aurora global databases aren’t available in all AWS Regions. For a list of supported Regions, see [Aurora global databases with Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.html#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.apg).
+ For information about features that aren’t supported and other limitations of Aurora global databases, see the [Limitations of Amazon Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database.limitations).
**Product versions**
+ Amazon Aurora PostgreSQL–Compatible Edition version 10.14 or later
## Architecture
**Source technology stack**** **
+ Oracle RAC four-node database
+ Oracle GoldenGate
**Source architecture**** **
The following diagram shows three clusters with four-node Oracle RAC in different AWS Regions replicated using Oracle GoldenGate.
**Target technology stack **
+ A three-cluster Amazon Aurora global database based on Aurora PostgreSQL–Compatible, with one cluster in the primary Region, two clusters in different secondary Regions
**Target architecture**
## Tools
**AWS services**
+ [Amazon Aurora PostgreSQL-Compatible Edition](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) is a fully managed, ACID-compliant relational database engine that helps you set up, operate, and scale PostgreSQL deployments.
+ [Amazon Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) span multiple AWS Regions, providing low latency global reads and fast recovery from the rare outage that might affect an entire AWS Region.
## Epics
### Add Regions with reader DB instances
| Task | Description | Skills required |
| --- | --- | --- |
| Attach one or more secondary Aurora clusters. | On the AWS Management Console, choose Amazon Aurora. Select the primary cluster, choose **Actions**, and choose **Add region** from the dropdown list. | DBA |
| Select the instance class. | You can change the instance class of the secondary cluster. However, we recommend keeping it the same as the primary cluster instance class. | DBA |
| Add the third Region. | Repeat the steps in this epic to add a cluster in the third Region. | DBA |
### Fail over the Aurora global database
| Task | Description | Skills required |
| --- | --- | --- |
| Remove the primary cluster from the Aurora global database. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/emulate-oracle-dr-by-using-a-postgresql-compatible-aurora-global-database.html) | DBA |
| Reconfigure your application to divert write traffic to the newly promoted cluster. | Modify the endpoint in the application with that of the newly promoted cluster. | DBA |
| Stop issuing any write operations to the unavailable cluster. | Stop the application and any data manipulation language (DML) activity to the cluster that you removed. | DBA |
| Create a new Aurora global database. | Now you can create an Aurora global database with the newly promoted cluster as the primary cluster. | DBA |
### Start the primary cluster
| Task | Description | Skills required |
| --- | --- | --- |
| Select the primary cluster to be started from the global database. | On the Amazon Aurora console, in the Global Database setup, choose the primary cluster. | DBA |
| Start the cluster. | On the **Actions** dropdown list, choose **Start**. This process might take some time. Refresh the screen to see the status, or check the **Status** column for the current state of the cluster after the operation is completed. | DBA |
### Clean up the resources
| Task | Description | Skills required |
| --- | --- | --- |
| Delete the remaining secondary clusters. | After the failover pilot is completed, remove the secondary clusters from the global database. | DBA |
| Delete the primary cluster. | Remove the cluster. | DBA |
## Related resources
+ [Using Amazon Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database-detaching)
+ [Aurora PostgreSQL Disaster Recovery solutions using Amazon Aurora Global Database](https://aws.amazon.com/blogs/database/aurora-postgresql-disaster-recovery-solutions-using-amazon-aurora-global-database/) (blog post)