We will be using us-east-1 as our secondary AWS region for Aurora Global Database.
Open the Amazon RDS service console in your primary AWS region. This is the same region where the Aurora cluster was created as part of the Prerequisites section or you created manually.
Click the radio button for the Aurora Cluster. Next go to Actions menu and click Add Region.
On the next screen we will take the following options as shown in the screenshots.
auroralab-postgres-global as the Global database identifier and choose
US East (N. Virginia) as the Secondary region.
Select the VPC
aupg-labs-vpc which was created as part of Cloudformation Stack. Choose
aupg-labs-aupf-internal in the Existing VPC security groups dropdown and remove the
default security group.
Expand Additional Configuration at the bottom of the screen.
auroralab-postgres-instance1 as the DB instance identifier and
auroralab-postgres-secondary as the DB cluster identifier. Select
apg-labstack-aupglabsrds-apgcustomclusterparamgro-####### as the DB cluster parameter group and
apg-labstack-aupglabsrdsstack-####### as the DB parameter group in their drop downs.
Under Monitoring, set Granularity of enhanced monitoring to
1 second and select
aupg-labs-monitor-us-east-1 in the Monitoring Role drop down.
Leave the rest of the inputs at default value. Finally, Click Add Region.
It normally takes 10-15 minutes to add a Region. Creating a global cluster based on the existing DB cluster is a seamless operation, your workload will not experience any disruption. Notice that we now have a cluster with role “Global”, one “Primary”, and one “Secondary”. The primary region is configured for High Availability. The secondary region contains one instance.
It’s also possible for Aurora Global Database to run “headless” in the secondary AWS region. This means that the secondary region will not have a running DB instance and just the Aurora storage layer. Aurora will replicate log records to Aurora storage in the secondary region to keep it in sync. You can add a replica and then promote the Aurora cluster in the secondary region as required in a DR scenario. For more information, please refer Creating a headless Aurora DB cluster in a secondary Region.
Click both the Primary and Secondary Clusters identifiers and note down the Primary Writer Endpoint and the Secondary Reader Endpoint in the Connectivity & security tab. You will need them later.
Primary AWS Region:
Secondary AWS Region:
You will notice that only the Reader Endpoint is provisioned with status Available for the secondary Aurora cluster. The secondary cluster cannot accept writes, therefore no cluster endpoint will be provisioned and will show an Inactive status. The Reader Endpoint will always resolve to one of the Reader DB instances and should be used for low latency local read operations within the same region.
Now, let’s move on to the next section.