9.1: Establish Global Database

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.

Add Region to Existing Cluster

On the next screen we will take the following options as shown in the screenshots. Enter auroralab-postgres-global as the Global database identifier and choose US East (N. Virginia) as the Secondary region.

Add Region 2

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.

Add Region 3

Enter 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.

Add Region 4

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.

Add Region 5

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.

Add Region 6

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:

Writer Endpoint

Secondary AWS Region:

Reader Endpoint

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.