Using Amazon Aurora global databases - Amazon Aurora
Overview of Aurora global databasesAdvantages of Amazon Aurora global databasesRegion and version availabilityLimitations of Aurora global databases
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Using Amazon Aurora global databases

Amazon Aurora global databases span multiple Amazon Web Services Regions, enabling low latency global reads and providing fast recovery from the rare outage that might affect an entire Amazon Web Services Region. An Aurora global database has a primary DB cluster in one Region, and up to five secondary DB clusters in different Regions.

Topics

Overview of Amazon Aurora global databases

By using an Amazon Aurora global database, you can run your globally distributed applications using a single Aurora database that spans multiple Amazon Web Services Regions.

An Aurora global database consists of one primary Amazon Web Services Region where your data is written, and up to five read-only secondary Amazon Web Services Regions. You issue write operations directly to the primary DB cluster in the primary Amazon Web Services Region. Aurora replicates data to the secondary Amazon Web Services Regions using dedicated infrastructure, with latency typically under a second.

In the following diagram, you can find an example Aurora global database that spans two Amazon Web Services Regions.

An Aurora global database has a single primary and at least one secondary Aurora DB clusters.

You can scale up each secondary cluster independently, by adding one or more Aurora Replicas (read-only Aurora DB instances) to serve read-only workloads.

Only the primary cluster performs write operations. Clients that perform write operations connect to the DB cluster endpoint of the primary DB cluster. As shown in the diagram, Aurora global database uses the cluster storage volume and not the database engine for replication. To learn more, see Overview of Amazon Aurora storage.

Aurora global databases are designed for applications with a worldwide footprint. The read-only secondary DB clusters (Amazon Web Services Regions) allow you to support read operations closer to application users. By using features such as write forwarding, you can also configure an Aurora MySQL–based global database so that secondary clusters send data to the primary. For more information, see Using write forwarding in an Amazon Aurora global database.

An Aurora global database supports two different approaches to failover. To recover your Aurora global database after an outage in the primary Region, you use the manual unplanned failover process. With this process, you fail over your primary to another Region (cross-Region failover). For more information about this process, see Recovering an Amazon Aurora global database from an unplanned outage.

For planned operational procedures such as maintenance, you use managed planned failover. With this feature, you can relocate the primary cluster of a healthy Aurora global database to one of its secondary Regions with no data loss. To learn more, see Performing managed planned failovers for Amazon Aurora global databases.

Advantages of Amazon Aurora global databases

By using Aurora global databases, you can get the following advantages:

  • Global reads with local latency – If you have offices around the world, you can use an Aurora global database to keep your main sources of information updated in the primary Amazon Web Services Region. Offices in your other Regions can access the information in their own Region, with local latency.

  • Scalable secondary Aurora DB clusters – You can scale your secondary clusters by adding more read-only instances (Aurora Replicas) to a secondary Amazon Web Services Region. The secondary cluster is read-only, so it can support up to 16 read-only Aurora Replica instances rather than the usual limit of 15 for a single Aurora cluster.

  • Fast replication from primary to secondary Aurora DB clusters – The replication performed by an Aurora global database has little performance impact on the primary DB cluster. The resources of the DB instances are fully devoted to serve application read and write workloads.

  • Recovery from Region-wide outages – The secondary clusters allow you to make an Aurora global database available in a new primary Amazon Web Services Region more quickly (lower RTO) and with less data loss (lower RPO) than traditional replication solutions.

Region and version availability

Feature availability and support varies across specific versions of each Aurora database engine, and across Amazon Web Services Regions. For more information on version and Region availability with Aurora and global databases, see Aurora global databases.

Limitations of Amazon Aurora global databases

The following limitations currently apply to Aurora global databases:

  • Aurora global databases are available in certain Amazon Web Services Regions and for specific Aurora MySQL and Aurora PostgreSQL versions only. For more information, see Aurora global databases.

  • Aurora global databases have certain configuration requirements for supported Aurora DB instance classes, maximum number of Amazon Web Services Regions, and so on. For more information, see Configuration requirements of an Amazon Aurora global database.

  • Managed planned failover for Aurora global databases requires one of the following Aurora database engines:

    • Aurora MySQL with MySQL 8.0 compatibility, version 3.01.0 and higher

    • Aurora MySQL with MySQL 5.7 compatibility, version 2.09.1 and higher

    • Aurora PostgreSQL versions 13.3 and higher, 12.4 and higher, 11.9 and higher, and 10.14 and higher

  • You can only perform a managed cross-Region database failover on an Aurora global database if the primary and secondary DB clusters have the same major, minor, and patch level engine versions. However, the patch levels can be different if the minor engine versions are one of the following.

    Database engine Minor engine versions

    Aurora PostgreSQL

    • Version 14.5 or higher minor version

    • Version 13.8 or higher minor version

    • Version 12.12 or higher minor version

    • Version 11.17 or higher minor version

    For more information, see Patch level compatibility for managed cross-Region failover.

  • Aurora global databases currently don't support the following Aurora features:

    • Aurora Serverless v1

    • Backtracking in Aurora

  • For limitations with using the RDS Proxy feature with global databases, see Limitations for RDS Proxy with global databases.

  • Automatic minor version upgrade doesn't apply to Aurora MySQL and Aurora PostgreSQL clusters that are part of an Aurora global database. Note that you can specify this setting for a DB instance that is part of a global database cluster, but the setting has no effect.

  • Aurora global databases currently don't support Aurora Auto Scaling for secondary DB clusters.

  • You can start database activity streams on Aurora global databases running the following Aurora MySQL and Aurora PostgreSQL versions only.

    Database engine Primary Amazon Web Services Region Secondary Amazon Web Services Regions

    Aurora MySQL 5.7

    version 2.08 and higher

    version 2.08 and higher

    Aurora PostgreSQL

    version 13.3 and higher

    version 13.3 and higher

    version 12.4 and higher

    version 12.4 and higher

    version 11.7 and higher

    version 11.9 and higher

    version 10.11 and higher

    version 10.14 and higher

    For information about database activity streams, see Monitoring Amazon Aurora with Database Activity Streams.

  • The following limitations currently apply to upgrading Aurora global databases:

    • You can't apply a custom parameter group to the global database cluster while you're performing a major version upgrade of that Aurora global database. You create your custom parameter groups in each Region of the global cluster and you apply them manually to the Regional clusters after the upgrade.

    • With an Aurora global database based on Aurora MySQL, you can't perform an in-place upgrade from Aurora MySQL version 2 to version 3 if the lower_case_table_names parameter is turned on. For more information on the methods that you can use, see Major version upgrades.

    • With an Aurora global database based on Aurora PostgreSQL, you can't perform a major version upgrade of the Aurora DB engine if the recovery point objective (RPO) feature is turned on. For information about the RPO feature, see Managing RPOs for Aurora PostgreSQL–based global databases.

    • With an Aurora global database based on Aurora MySQL, you can't perform a minor version upgrade from version 3.01 or 3.02 to 3.03 or higher by using the standard process. For details about the process to use, see Upgrading Aurora MySQL by modifying the engine version.

    For information about upgrading an Aurora global database, see Upgrading an Amazon Aurora global database.

  • You can't stop or start the Aurora DB clusters in your Aurora global database individually. To learn more, see Stopping and starting an Amazon Aurora DB cluster.

  • Aurora Replicas attached to the secondary Aurora DB cluster can restart under certain circumstances. If the primary Amazon Web Services Region's writer DB instance restarts or fails over, Aurora Replicas in secondary Regions also restart. The secondary cluster is then unavailable until all replicas are back in sync with the primary DB cluster's writer instance. The behavior of the primary cluster when rebooting or failing over is the same as for a singular, nonglobal DB cluster. For more information, see Replication with Amazon Aurora.

    Be sure that you understand the impacts to your Aurora global database before making changes to your primary DB cluster. To learn more, see Recovering an Amazon Aurora global database from an unplanned outage.

  • Aurora PostgreSQL–based DB clusters running in an Aurora global database have the following limitations:

    • Cluster cache management isn't supported for Aurora PostgreSQL DB clusters that are part of Aurora global databases.

    • If the primary DB cluster of your Aurora global database is based on a replica of an Amazon RDS PostgreSQL instance, you can't create a secondary cluster. Don't attempt to create a secondary from that cluster using the Amazon Web Services Management Console, the Amazon CLI, or the CreateDBCluster API operation. Attempts to do so time out, and the secondary cluster isn't created.

We recommend that you create secondary DB clusters for your Aurora global databases by using the same version of the Aurora DB engine as the primary. For more information, see Creating an Amazon Aurora global database.