Amazon Aurora Global Database is specifically designed to meet the needs of globally distributed applications. It replicates your data across AWS Regions with no impact on database performance, enables fast local reads with low latency in each Region, and provides disaster recovery from Region-wide outages.
Many organizations use Aurora Global Database in a headless configuration. An Aurora global database in a headless configuration is essentially an Aurora database cluster that operates without a database instance in the secondary Region. Upgrading an Aurora global database in a headless configuration is necessary to ensure that the database is up to date with the latest security patches, bug fixes, and performance improvements.
When implementing an upgrading strategy, we recommend upgrading the primary and secondary Aurora DB clusters to the same version to avoid incompatibility during failover. Upgrading an Aurora global database in a headless configuration follows similar procedures as upgrading an Aurora global database. However, there are some important differences to take note of before you start the process.
In this post, we provide an overview of Aurora global database patching in a headless configuration and guide you through the extra measures to upgrade the database in such a setup.
Overview of solution
The following diagram illustrates the headless Amazon Aurora database cluster architecture. There is an Aurora database cluster in the primary region comprises a writer instance, and one or more replicas in the same or different Availability Zone, along with a cluster volume that represents the primary database cluster’s data. The secondary Region contains the cluster volume that represents the data for the secondary database cluster.
For the list of Regions where Aurora global databases are available, refer to Aurora global databases. Let’s look at how to carry out both major and minor upgrades in this Aurora database headless configuration.
Major version upgrades in a headless configuration:
To perform a major version upgrade of an Aurora global database in a headless configuration, you upgrade the global database cluster instead of the individual clusters that it contains. This process is the same as upgrading an Aurora global database.
To learn how to upgrade an Amazon Aurora PostgreSQL-Compatible Edition global database to a higher major version, see Major upgrades for global databases.
To learn how to upgrade an Amazon Aurora MySQL-Compatible Edition global database to a higher major version, see In-place major upgrades for global databases.
Minor version upgrades in a headless configuration:
For a minor upgrade on an Aurora global database in a headless configuration, you must upgrade all the secondary DB clusters before you upgrade the primary DB cluster. Additionally, the secondary DB cluster must have at least one DB instance to proceed with the upgrade. Because an Aurora global database in a headless configuration doesn’t have any DB instances in the secondary DB cluster, you need to add an instance before initiating a minor version upgrade and then remove it as part of the post-upgrade process.
Note that an automatic minor version upgrade doesn’t apply to Aurora MySQL and Aurora PostgreSQL clusters that are part of an Aurora global database. You can specify this setting for a DB instance that is part of a global database cluster, but the setting has no effect.
Prerequisites:
This post assumes that you have an Aurora global database in a headless configuration. For instructions, refer to Achieve cost-effective multi-Region resiliency with Amazon Aurora Global Database headless clusters.
Additionally, you need basic familiarity with the AWS Management Console, an AWS account, and access to Amazon Relational Database Service (Amazon RDS).
Convert an Aurora global database cluster in a headless configuration to an Aurora global database
In this section, we change the Aurora global database configuration to add an instance in a headless cluster.
On the Amazon RDS console, choose Databases in the navigation pane. This page provides details on the primary and secondary Regions for Aurora global databases.
To add a DB instance to the secondary cluster in a headless configuration, you must use AWS Command Line Interface (AWS CLI):
Return to the Amazon RDS console to confirm your configuration.
Note: Aurora global databases come with specific configuration requirements, such as supported Aurora DB instance classes, maximum number of Regions, and other related factors. For more information, see Configuration requirements of an Amazon Aurora global database.
Perform a minor upgrade on the Aurora global database secondary cluster
By adding a DB instance to the secondary DB cluster, we have removed the headless configuration. Now, our next step is to carry out a minor upgrade for this cluster.
On the Amazon RDS console, choose Databases in the navigation pane.
Navigate to the Region where the secondary cluster is running and choose Modify.
For Engine version, choose your minor engine version and Choose Continue.
To carry out a managed cross-Region database failover for an Aurora MySQL, it’s crucial that both the primary and secondary DB clusters have identical engine versions in terms of major, minor, and patch levels.
Note: With Aurora PostgreSQL you may perform a managed cross-Region database failover even if the patch levels of your primary and secondary DB clusters don’t match. See Patch level compatibility for managed cross-Region failover for more details.
Select Apply immediately and choose Modify cluster
Currently, there exists a mix of minor versions between the global database clusters functioning in the primary and secondary Regions. To revert to the headless configuration, you can remove the instance located in the secondary Region.
On the Amazon RDS console, choose Databases in the navigation pane.
Select the instance in the secondary cluster on the Actions menu, choose Delete.
Navigate to the primary cluster and modify it to use the same minor version as the secondary cluster.
Select Apply immediately and choose Modify cluster.
This completes the minor upgrade of your Aurora global database in a headless configuration. Alternatively, you can also use AWS CLI to perform upgrade. For more information on modifying Amazon Aurora DB clusters, see modify-db-cluster.
Conclusion
In this post, we walked through upgrading an Aurora global database with a headless configuration in a secondary Region. Taking a proactive approach to patch management can save your organization valuable time and resources by preventing costly security breaches. Use this procedure to keep Aurora global database in a headless configuration up to date with the latest security patches, bug fixes, and performance improvements.
If you have any questions or suggestions, leave your feedback in the comment section.
About the Authors
 Rajbir Singh is Technical Account Manager, specializes in helping clients integrate their business processes with the AWS cloud to achieve operational excellence and efficient resource utilization. Rajbir’s primary focus is to optimize workload performance, whether through lift-and-shift migrations or cloud-native refactoring, to ensure optimal cost efficiency.
Kanwar Bajwa is enterprise support lead at AWS who works with customers to optimize their use of AWS services and achieve their business objectives. He serves as their primary technical point of contact, providing proactive guidance and support to ensure that their AWS environments are running efficiently and effectively. Kanwar helps customers design and implement solutions, troubleshoot issues, and optimize their AWS environments.
Read MoreAWS Database Blog
