AWS Database Blog

Aurora PostgreSQL Disaster Recovery solutions using Amazon Aurora Global Database

Amazon Aurora with PostgreSQL compatibility combines the performance and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Aurora provides this by scaling storage across three Availability Zones in the same Region, and supports up to 15 read replica instances for scaling out read workloads and high availability within a single Region. With Amazon Aurora Global Database, you can now replicate PostgreSQL databases in up to five Regions for remote read access and disaster recovery in the event of the failure of an entire Region.

Aurora builds its storage volumes in 10-GB logical blocks called protection groups. Aurora replicates the data in each protection group across six storage nodes allocated across three Availability Zones (AZ) in the same Region, with two storage nodes in each AZ. If the volume of data exceeds the currently allocated storage, Aurora automatically expands the volume to meet the demand by adding new protection groups as necessary.

What is an Aurora Global Database?

An Aurora Global Database spans multiple Regions, provides disaster recovery from Region-wide outages and enables low-latency global reads by allowing reads from the nearest Aurora cluster.

As a feature of Aurora, Global Database uses dedicated infrastructure in Aurora’s purpose-built storage layer to handle replication across Regions. Dedicated replication servers in the storage layer handle the replication, which allows you to meet enhanced recovery and availability objectives without compromising database performance.

PostgreSQL logical replication and the storage-based replication that Aurora Global Database uses have a few key differences. Logical replication uses native PostgreSQL replication slots to record data-modifying statements or row changes on the replication source (primary) and reapply them on the replication target (replica). The primary and replica databases are separate and independent and can contain different datasets.

In contrast, Aurora Global Database employs physical storage-level replication to create a replica of the primary database with an identical dataset, which removes any dependency on the logical replication process. This eliminates overhead on your primary write server that would otherwise be required to support logical replication. The secondary Region instances of the Aurora Global Database do not replay data-modifying statements. This dramatically reduces replication overhead and leaves more capacity available for application workloads.

This means that committed transactional changes from the writer are replicated globally to the Regions that you select, typically within 1 second. While the Aurora Global Database handles this replication, the data remains durably stored in three Availability Zones in each Region of your cluster.

Why use global databases?

Aurora Global Database provides several important features:

  • Fast global failover to secondary Regions
  • Low replication lag across Regions
  • Little to no performance impact on your database
  • Up to five regional replicas with up to 16 read replicas per Region
  • Compatibility with MySQL or PostgreSQL

Fast global failover to secondary Regions

A solid disaster recovery plan allows you to place greater confidence in your business continuity plans if an unexpected event occurs. Aurora Global Database excels at two important metrics of disaster recovery:

  • Recovery time objective (RTO) – How long it takes you to return to a working state after a disaster
  • Recovery point objective (RPO) – How much data you could lose

Aurora Global Database provides disaster recovery and the ability to continue operating even in the face of a Region-wide failure. An Aurora Global Database quickly responds to promote a secondary Region during a potential degradation or isolation of your database. With global storage-based replication, this promoted Region can take full read/write workloads in under a minute, which minimizes the impact on application uptime.

Low replication latency across Regions

Beyond providing disaster recovery, Aurora Global Database allows you to offload reads from the primary Region to multiple secondary Regions quickly. Aurora Global Database maintains typical replication latencies of less than 1 second. This low latency grants global read scale-out for online transaction processing (OLTP) workloads. You can choose up to five secondary Regions for replication.

Aurora Global Database reduces latency and provides faster global client application database response times for optimal user experience and engagement by placing global replicas much closer to end-user applications. If you operate multi-region application stacks that share common configuration data, you can rely on Aurora Global Database to replicate data almost instantaneously.

If you have multiple offices around the world and a global customer base, you can upload your content in the primary Region and make it available to customers around the world with local latency.

Little to no performance impact on your database

The Aurora Global Database dedicated infrastructure in the Aurora storage layer keeps the database resources provisioned in the primary and secondary Regions fully available to serve application workloads. Aurora replication has limited to no impact on the primary database cluster’s performance.

Fast cross-Region migrations

Aurora Global Database can replicate production databases to another AWS Region for application migrations. After Aurora Global Database updates the secondary Region, you can detach the replicated database from the Aurora Global Database and operate it like any other Aurora database cluster. As soon as you connect the now-independent cluster to the Region’s application stack, it begins serving read/write workloads.

Compatibility

Aurora Global Database was previously available for Amazon Aurora with MySQL compatibility. With this change, Aurora Global Database is now available for Amazon Aurora with PostgreSQL compatibility. This first release applies to Aurora PostgreSQL 2.4, which is compatible with PostgreSQL 10.11. Because Aurora is compatible with both MySQL and PostgreSQL, application developers benefit from the familiarity and flexibility of open-source databases, even on a global scale.

Creating an Aurora Global Database

You can create an Aurora Global Database from the AWS Management Console, AWS CLI, or by running the CreateGlobalCluster action from the AWS CLI or SDK. For more information, see Creating an Aurora Global Database.

The following screenshot shows two Aurora Global Database clusters, one for MySQL and one for PostgreSQL. For the highlighted Aurora PostgreSQL Global Database, the primary cluster is in US East (N. Virginia) and the secondary cluster is in US East (Ohio). For instructions on adding secondary clusters, see Adding an AWS Region to an Aurora Global Database.

For information about removing a cluster from an Aurora Global Database, performing a failover, or importing data, see Working with Amazon Aurora Global Database.

Summary

Aurora Global Database is now available to provide regional read replicas and disaster recovery capabilities for Amazon Aurora with PostgreSQL compatibility. With this capability, global data replication is easy to implement. Disaster recovery capabilities for the failure of an entire Region is just a matter of enabling a replica for your PostgreSQL databases; AWS provides the implementation and infrastructure.

 

About the Authors

 

Richard Waymire is a Principal Outbound Architect at Amazon Web Services. He works with AWS customers to provide guidance and technical assistance on database projects, helping them improve the value of their solutions when using AWS.

 

 

 

Ahmad Elayat is a Senior Product Manager with Amazon Web Services.