Manage the Aurora PostgreSQL global database

Introduction

You can use the AWS Console Manager to manage the Aurora PostgreSQL global database, alternatively, you can manage the Aurora PostgreSQL global database using the AWS CLI in Linux(AWS Cloud9 for my lab) as below.

Guide to creating and managing the Aurora PostgreSQL global database using the AWS CLI.

This lab contains the following tasks

Create Aurora Postgresql global database from a Regional cluster using AWS CLI

Add reader instances in the Secondary Aurora DB cluster using AWS CLI

Perform a Managed Planned Failover to the secondary region using AWS CLI

Detaches an Aurora secondary cluster from an Aurora global database cluster using AWS CLI

Prerequisites

For this walkthrough, you should have the following prerequisites configured:

• Amazon Aurora PostgreSQL cluster in a single region
• AWS CLI environment deployed
• Cluster Parameter Group Name, VPC Security Group, and DB Subnet Group were deployed into the primary region and the secondary region

Detail Steps

Create Aurora Postgresql global database from a Regional cluster using AWS CLI

On the primary AWS Region, execute the below code using AWS CLI

# Get current cluster ARN
CLUSTER_ID=`aws rds describe-db-clusters --db-cluster-identifier aupg-labs-cluster --query 'DBClusters[*].DBClusterArn' | jq -r '.[0]'`

# convert the Aurora Provisioned cluster to global
aws rds create-global-cluster  --global-cluster-identifier auroralab-postgres-global --source-db-cluster-identifier $CLUSTER_ID

This operation will take 2-5 minutes to complete. 

In the next step, perform the following actions using AWS CLI to add a secondary region.

# obtain KeyID of the KMS key in the secondary region
aws kms describe-key --key-id alias/aws/rds --region us-west-1 --query 'KeyMetadata.KeyId'

# create the secondary cluster
aws rds --region us-east-1 \
  create-db-cluster \
     --db-cluster-identifier auroralab-postgres-secondary \
     --global-cluster-identifier auroralab-postgres-global \
     --engine aurora-postgresql \
     --kms-key-id d71e19d3-24a3-48cb-9e7f-10fbd28ef271 \
     --engine-version 15.3 \
     --db-cluster-parameter-group-name rds-apgcustomclusterparamgroup \
     --db-subnet-group-name aupg-labs-db-subnet-group \
     --vpc-security-group-ids sg-0cdcd29e64fd436c6 \
     --backup-retention-period 7 --region us-west-1

This operation will take 5-10 minutes to complete. 

Add reader instances in the Secondary Aurora DB cluster using AWS CLI

# Database Parameter group
DB_PARAMETER_GP=`aws rds describe-db-parameter-groups --region us-west-1 --query 'DBParameterGroups[*].DBParameterGroupName' | jq -r '.[0]'`

# Enhanced Monitoring role ARN
MONITOR_R=`aws iam get-role --role-name aupg-labs-monitor-us-west-2 --query 'Role.Arn' --output text`

# Add a Reader instance to the secondary Aurora DB cluster
aws rds --region us-west-1 \
  create-db-instance \
     --db-instance-identifier auroralab-postgres-instance1 \
     --db-cluster-identifier auroralab-postgres-secondary \
     --db-instance-class db.r6g.large \
     --engine aurora-postgresql \
     --enable-performance-insights \
     --performance-insights-retention-period 7 \
     --db-parameter-group-name $DB_PARAMETER_GP \
     --monitoring-interval 1 \
     --monitoring-role-arn $MONITOR_R \
     --no-auto-minor-version-upgrade

This operation will take 5-10 minutes to complete. 

Perform a Managed Planned Failover to the secondary region using AWS CLI

This method is recommended for disaster recovery. When you use this method, Aurora automatically adds back the old primary Region to the global database as a secondary Region when it becomes available again. Thus, the original topology of your global cluster is maintained.

Before failover

Failover

aws rds failover-global-cluster --global-cluster-identifier auroralab-postgres-global --target-db-cluster-identifier arn:aws:rds:us-west-1:XXXXXXXXX:cluster:auroralab-postgres-secondary

Now that the managed failover is completed.

To recover from an unplanned outage refer Recovering an Amazon Aurora global database from an unplanned outage

This alternative method can be used when managed failover isn’t an option, for example, when your primary and secondary Regions are running incompatible engine versions.

Detaches an Aurora secondary cluster from an Aurora global database cluster using AWS CLI

aws rds remove-from-global-cluster --global-cluster-identifier auroralab-postgres-global --db-cluster-identifier arn:aws:rds:us-west-2:XXXXXXXX:cluster:aupg-labs-cluster

This operation will take 5-10 minutes to complete. 

Now that the detach is completed.

And latest, the global database can be deleted with a command, see the AWS CLI document here:

aws rds delete-global-cluster --global-cluster-identifier <value>

Conclusion

These steps provide a general AWS CLI of the process of managing the Aurora global Postgresql instance. The specific configuration details may vary depending on your environment and setup. It’s recommended to consult the relevant documentation from AWS for detailed instructions on setting up.

Manage the Aurora PostgreSQL global database

I hope will this be helpful. Thank you for reading the DevopsRoles page!