Fast cross-region disaster recovery and low-latency global reads
In this tutorial, you will learn how to create an Amazon Aurora Global Database deployment that spans multiple AWS Regions and replicates your data with little to no impact on performance. Aurora Global Database provides disaster recovery from Region-wide outages and enables low-latency global reads.
Amazon Aurora is a MySQL and PostgreSQL-compatible relational database that combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open source databases.
An Aurora Global Database consists of a primary AWS Region —where your data is mastered— and multiple read-only secondary AWS Regions where the data is replicated. Your writes go to the primary database, but you can read from any Region and benefit from low latency.
This tutorial will use Amazon Aurora with MySQL compatibility for illustration. However, the concepts and steps are the same for Aurora with PostgreSQL compatibility. The tutorial is not within the free tier, but it will cost you less than $2 provided you follow the steps in the tutorial and terminate your resources at the end of the tutorial.
An Amazon Aurora DB cluster consists of one or more DB instances and a cluster volume that manages the data for those DB instances. An Aurora cluster volume is a virtual database storage volume that spans multiple Availability Zones, with each Availability Zone having two copies of the DB cluster data. Two types of DB instances make up an Aurora DB cluster: a Primary DB instance, which supports read and write operations, and an Aurora Replica, which connects to the same storage volume as the primary DB instance and supports read only operations. Each Aurora DB cluster can have up to 15 Aurora Replicas located across the three Availability Zones. Aurora automatically fails over to an Aurora Replica in case the primary DB instance becomes unavailable.
In this tutorial, you will create an Aurora Global Database with a primary cluster in one Region and a secondary cluster in a different Region. Which Regions to use is up to you. In an Aurora Global Database, you will deploy your application to read and write from a primary cluster and configure applications to use secondary clusters for low latency reads or disaster recovery purposes. For example, if your Aurora Global Database will have a primary cluster in US East (N. Virginia) and a secondary cluster in Europe (Paris), you could have an Application instance in US East (N. Virginia) and another one for reads in Europe (Paris).
Also, if you want to save time, for each of those Regions you can create a Security Group allowing incoming connections from your instances. For example, you can create a security group with an inbound rule allowing TCP connections on port 3306 (for MySQL) or 5432 (for PostgreSQL) from the security group of your instances.
Finally, in order to test your Aurora Global Database (see Step 7), you will need a MySQL or PostgreSQL client. If your application instances are running on Amazon Linux, installing a MySQL client can be as simple as running sudo yum install mysql (for MySQL) or sudo amazon-linux-extras install postgresql10 vim epel and sudo yum install -y postgresql-server postgresql-devel (for PosgreSQL) , but the exact command depends on the OS you are running. If you are running Windows, you can download MySQL workbench or pgAdmin instead.
|About this Tutorial|
|Cost||Less than $1|
|Products||Amazon Aurora, Amazon RDS|
|Audience||Database administrators, Developers|
|Last Updated||July 8, 2020|
1.2 — On the top right corner, select the region where you want to launch the primary Aurora DB cluster. For the purposes of this tutorial, we will use US East (N. Virginia) as the primary region and Europe (Paris) as the secondary region.
1.3 — Click on “Create database” in the Amazon Aurora window.
2.1 — On Choose a database creation method, select Standard Create.
2.2 — On Engine type, select “Amazon Aurora”.
2.3 — On Edition, select “Amazon Aurora with MySQL compatibility” or PostgreSQL compatibility based on your interest.
2.4 — On Capacity type, select "Provisioned" mode.
2.5 — In Replication features, ensure "Single-master" is checked.
2.6 — On Version, select the most recent MySQL or PostgreSQL version supported by Aurora Global Database.
For Aurora Global Database availability for specific MySQL or PostgreSQL versions or Region, see working with Amazon Aurora Global Database.
2.7 — On Templates, choose Dev/Test.
3.1 — For the Global database identifier, type “global-database-1”.
3.2 — For the Credentials Settings, leave the master username as-is. Type a master password and keep a note of it. We suggest entering a password that you can remember for later use.
3.3 — For the DB instance size, select a large instance (ending with r5.large, or a similar instance size from a newer generation if available).
3.4 — For Availability & durability, choose “Don't create an Aurora Replica”.
Note that having an Aurora Replica is recommended for production environments, as it allows you to scale reads and it gives you automatic failovers within the same Region as your primary database. In this tutorial we are not adding an Aurora Replica just to keep the exercise simple.
4.1 — Select VPC where you want to create the database. We will use the default VPC created for each Region in your account.
Note that once created, a database can't be migrated to a different VPC.
4.2 — Select the default value for Subnet group.
4.3 — On Publicly accessible, select “No”.
This means you will have to connect to the database from an EC2 instance within the same VPC.
4.4 — On VPC security group, select “Create new”. If you happen to have a security group that allows incoming TCP connections on port 3306 for MySQL or 5432 for PostgreSQL, you can choose it instead.
4.5 — In New VPC security group name, type “global-database-sg”.
4.6 — Click on “Additional configuration”
4.7 — Leave the default value for Database port.
5.1 — Choose Password Authentication for Database Authentication options.
5.2 — Under Additional configuration section, leave the default values for Database options, Encryption, Backup, Monitoring, Log exports, Maintenance except the Deletion Protection. For Deletion protection, uncheck the Enable deletion protection option as you may want to terminate the instance at the end of the tutorial.
5.3 — Click on “Create database”. It will take a few minutes to create.
6.1 — Go to RDS Console in US East (N. Virginia). Select “global-database-1”.
6.2 — Click on “Actions > Add a Region”. When you add a Region to the cluster, this becomes a primary cluster in an Aurora Global Database.
6.3 — Type Global database identifier as “global-database”
6.4 — Choose the Secondary Region as EU (Paris)
6.5 — Repeat steps 3.3 to 5.3 for the secondary Region.
The creation process will take about ~20 minutes. Once the secondary cluster becomes available, proceed to Step 7.
Note: If you see error such as “The specified KMS key [arn:aws:kms:<AWS Region>:<AWS Account>:key/alias/aws/rds] does not exist, etc, Please retry the Step 6. This error happens when you create a secondary cluster first time in that AWS Region.
7.1 — Make sure you are in US East (N. Virginia) Region. Click on your primary cluster “global-database-1”.
7.2 — Copy the Writer endpoint.
Open two terminal windows, log into your EC2 instances in the primary and secondary Regions, and use the mysql or PostgreSQL command line client to connect to the databases.
You can now create a database, create a table and write some records. Everything you write to the primary region will be replicated to the secondary region.
7.3 — Connect to your primary aurora cluster in US East (N. Virginia):
$ mysql -h <Primary Cluster Writer Endpoint> -P 3306 -u admin -p
When prompted for a password, enter the password you saved in the step 3.2.
7.4 — Create a database
mysql> CREATE database tutorial;
Query OK, 1 row affected (0.01 sec)
At this point, you can use the tutorial database, create tables and add some records.
7.5 — Create a test table and write some data. For example:
create table employee (emp_no bigint, name varchar(50));
insert into employee values (1, 'John');
insert into employee values (2, 'Sam');
select * from employee;
$ psql -h <Primary Cluster Writer Endpoint> -d postgres -p 5432 -U admin
When prompted for a password, enter password you saved in the step 3.2.
Repeat the SQL commands from step 7.5.
7.6 — Go to the secondary region Europe (Paris).
7.7 — Click on your secondary cluster.
7.8 — Copy the Reader endpoint.
7.9 — Connect to your secondary cluster in Europe (Paris):
$ mysql -h <Secondary Reader Endpoint> -P 3306 -u admin -p
When prompted for a password, enter password you saved in the step 3.2.
7.10 — Read some data:
mysql> USE tutorial;
mysql> select * from employee;
$ psql -h <Secondary Reader Endpoint> -d postgres -p 5432 -U admin
postgres=> select * from employee;
Now you can verify that the primary database has been replicated to the secondary database.
While a default Aurora cluster gives you failover capabilities within the Region, Aurora Global Database allows you to failover to a secondary cluster in a different Region. It means your database will survive even in the unlikely event of a regional degradation of storage.
You can manually perform a failover by following the instructions below.
8.1 — Stop writing to the primary cluster.
8.2 — Make sure you click on “global-database” either in the primary region or the secondary region.
8.3 — Click on “Actions > Fail over global database”
8.4 — In the “Fail over global-database global database?” window, click on the dropdown to choose the target secondary region and choose “global-database-cluster-1”.
8.5 — Confirm by clicking on “Fail over global database”.
8.6 — After a few seconds you can see that the status of the “global-database” reflects as “Failing over”.
8.7 — After the regional managed failover completes successfully, observe that the roles of the regions interchange, that is eu-west-3 (Paris) region becomes Primary and the previous primary region of us-east-1 (N. Virginia) becomes Secondary region.
To finish this tutorial, you will need to delete your Aurora Global Database. You can keep it around, but be aware that you will incur charges.
In order to delete your Aurora Global Database, go to the RDS Dashboard and follow these instructions in each Region:
9.1 — Select “Databases” on the left pane in US East (N. Virginia) Region.
This will show you a list of all your Aurora DB clusters.
9.2 — Select “global-database-1” cluster which is the current Secondary region cluster.
9.3 — Before deleting an instance and the cluster in a global database, you need to remove it from Global database.
9.4 — Click on “Actions > Remove from global database”.
9.5 — Confirm by clicking on “Remove and promote”.
9.6 — Once the “global-database-1” cluster in N. Virginia becomes a standalone Regional cluster, you can perform deletion by clicking on the instance and “Actions > Delete”.
9.7 — You will be asked if you want to create a final snapshot. That's usually a good idea for real data, but it's not necessary for this tutorial. Choose the option “I acknowledge.” and Confirm by typing, “delete me” and click “Delete”.
The status of your cluster will change to “Deleting”.
9.8 — Repeat the above steps to remove the Aurora Cluster in in Europe (Paris) Region as well.
You have created an Aurora Global Database with replication across regions. You have learned how to scale reads to other regions in order to benefit from lower latency, and you have performed a failover to a secondary region.