6.7 Aurora

Introduction

Not like other software, for example, MySQL, you can run it locally or you can run it on AWS, Aurora can only run on AWS infrastructure.

Amazon Aurora is a MySQL-compatible, relational database engine that combines the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Aurora provides up to five times better performance than MySQL at a price point one tenth that of a commercial database while delivering similar performance and availability. You are always prompted to use Aurora when you are logging into RDS.

Aurora Scaling

Start with 10 GB, scales in 10 GB increments to 64 TB (storage auto-scaling). You don't need to worry about provisioning more storage or anything like that.
Compute resources can scale up to 32vCPUs and 244 GB of memory. So it is push button scaling. It is not like DynamoDB in the sense that you won't have any downtime. When you do scale Aurora, you would normally do this during a maintenance window. That being said though to scale up an Aurora instance actually only takes a couple of minutes, so it is quite quick in terms of how fast it can scale.
2 copies of your data is contained in each availability zone, with minimum of 3 availability zones. It means effectively you've got 6 copies of your data.
Aurora is designed to transparently handle the loss of up to 2 copies of data without affecting database write availability and up to 3 copies without affecting read availability. So it is really highly redundant.
Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.

Aurora Replicas

2 Types of Replicas are available.
- Aurora Replicas. These replicas are basically a separate Aurora database from your original Aurora database and you can have up to 15 Aurora replicas.
- MySQL Read Replicas. These replicas are just like, with MySQL, you would normally have an RDS, so you can have to up to 5 MySQL read replicas. The key difference between an Aurora replica and a MySQL read replica is the failover. So if you do lose your primary Aurora database for whatever reason, failover will automatically occur to your Aurora replica. It will not automatically occur over to MySQL read replicas however.

Lab Steps:

Aurora is only available in certain region. Go to RDS, you can see which regions are supporting Aurora.
Go to launch DB and select MySQL, you can see the Aurora is in the production options. Click next.
For the DB instance class, you cannot select t2-micro anymore, you can only select one from the some specific more powerful instances.
For multi-AZ deployment, you can create replica in different zone. You can also create replicas after created this instance.
Give a DB instance identifier, master username, master password.
For the failover, there are up to 15 tiers. This indicate what is the priority of this instance. Tier 0 > Tier 1 > ... > Tier 15. Select Tier 0 for the primary instance.
For the VPC, leave it in the default VPC.
For VPC security group, you could select MyRDSSecurityGroup (VPC) which you created before.
For public accessible, you can select Yes.
For Availability Zone, you can select No preference.
For the Database Options. You can give it a DB cluster identifier. This is going to make up the DNS address of your Aurora instance.
Give it a Database name and enable the encryption. For simple, we can disable the encryption for now.
For backup, you can set the backup retention period to be from 1 days to 35 days. Default is 1 day, very similar to RDS.
For monitoring, because we have CloudWatch, so here we can leave it as No.
You can also set the maintenance window.
Launch the instance.
If you turn multi-AZ on, you need to create more Aurora instances.
Go to Instances of your RDS Dashboard. You can see your Aurora instance is available. The Replication Role can be Writer or Reader. Here for this primary instance, it is Writer.
You should remember that we have 6 copies of our data spread across 3 availability zones. It is still important to remember that Aurora is running of a virtual machine, and this virtual machine is a single point of failure, and this virtual machine is going to sit inside a EU-WEST-1c (we launch this Aurora instance in Ireland for now), so this virtual machine did fail although storage is spread across 6 availability zones. I mean, though the data has copies and we didn't lost our data, but this particular machine is failed. Let's say we lost EU-WEST-1c as our availability zone, we need to automatically failover to another availability zone. The way to do this is to create an Aurora replica.
Go to create a Aurora replica. Select the Aurora instance you created just now, click Instance Actions -> create Aurora replica.
You need to choose the source database of this replica and give it an identifier as well. Normally you just need to select the same instance class with the source instance.
Publicly accessible - Yes
Availability zone - No preference. Amazon will automatically put it to a separate one to our primary instance.
Failover priority could be Tier 1. Tier 1 is the first place that the primary instance will fail over to.
Leave everything else as default and click launch.
When the replica becomes available, you can see the replication role of it is reader, and you cannot write to it.
You can see the Cluster Endpoint has been generated and it has made up this DNS end point name, and this is what you use in your connection strings for your applications in order to connect into the database.
You can see the Multi-AZ. It says 2 zones. If I add another Aurora replica of the primary instance, then it will say 3 zones etc. You can have more than 2 zones and you can have up to as many availability zones that within your Region as possible. So if you are in the US-EAST-1 region, you can have up to 4 zones.
Compare the primary instance with the replica. You can notice that the primary instance has Cluster Endpoint (DNS address for the cluster), and the replica has Instance Endpoint (DNS address for this particular instance). If the primary instance failed, the cluster DNS address is automatically failover to the instance end point, so you don't need to go in and update your connection strings, because Amazon handle all the failover. So always use the Cluster Endpoint when you are putting this into connection strings, instead of Instance Endpoint.
Select one of instances, go to Instance Actions -> Failover, you can actually do a failover. You can also Take Snapshot or Restore to Point in Time or Delete. When you delete the replica and the primary instance, the deleting completion of replica must happen before the deleting completion of the primary instance, because we can delete the cluster only when we have deleted the replicas.

Previous6.6 ElastiCache Next6.8 Database Summary

Last updated 5 years ago

Was this helpful?

Introduction

Not like other software, for example, MySQL, you can run it locally or you can run it on AWS, Aurora can only run on AWS infrastructure.

Aurora Scaling

Start with 10 GB, scales in 10 GB increments to 64 TB (storage auto-scaling). You don't need to worry about provisioning more storage or anything like that.

Compute resources can scale up to 32vCPUs and 244 GB of memory. So it is push button scaling. It is not like DynamoDB in the sense that you won't have any downtime. When you do scale Aurora, you would normally do this during a maintenance window. That being said though to scale up an Aurora instance actually only takes a couple of minutes, so it is quite quick in terms of how fast it can scale.

2 copies of your data is contained in each availability zone, with minimum of 3 availability zones. It means effectively you've got 6 copies of your data.

Aurora is designed to transparently handle the loss of up to 2 copies of data without affecting database write availability and up to 3 copies without affecting read availability. So it is really highly redundant.

Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.

Aurora Replicas

2 Types of Replicas are available.

Aurora Replicas. These replicas are basically a separate Aurora database from your original Aurora database and you can have up to 15 Aurora replicas.
MySQL Read Replicas. These replicas are just like, with MySQL, you would normally have an RDS, so you can have to up to 5 MySQL read replicas. The key difference between an Aurora replica and a MySQL read replica is the failover. So if you do lose your primary Aurora database for whatever reason, failover will automatically occur to your Aurora replica. It will not automatically occur over to MySQL read replicas however.

Lab Steps:

Aurora is only available in certain region. Go to RDS, you can see which regions are supporting Aurora.

Go to launch DB and select MySQL, you can see the Aurora is in the production options. Click next.

For the DB instance class, you cannot select t2-micro anymore, you can only select one from the some specific more powerful instances.

For multi-AZ deployment, you can create replica in different zone. You can also create replicas after created this instance.

Give a DB instance identifier, master username, master password.

For the failover, there are up to 15 tiers. This indicate what is the priority of this instance. Tier 0 > Tier 1 > ... > Tier 15. Select Tier 0 for the primary instance.

For the VPC, leave it in the default VPC.

For VPC security group, you could select MyRDSSecurityGroup (VPC) which you created before.

For public accessible, you can select Yes.

For Availability Zone, you can select No preference.

For the Database Options. You can give it a DB cluster identifier. This is going to make up the DNS address of your Aurora instance.

Give it a Database name and enable the encryption. For simple, we can disable the encryption for now.

For backup, you can set the backup retention period to be from 1 days to 35 days. Default is 1 day, very similar to RDS.

For monitoring, because we have CloudWatch, so here we can leave it as No.

You can also set the maintenance window.

Launch the instance.

If you turn multi-AZ on, you need to create more Aurora instances.

Go to Instances of your RDS Dashboard. You can see your Aurora instance is available. The Replication Role can be Writer or Reader. Here for this primary instance, it is Writer.

You should remember that we have 6 copies of our data spread across 3 availability zones. It is still important to remember that Aurora is running of a virtual machine, and this virtual machine is a single point of failure, and this virtual machine is going to sit inside a EU-WEST-1c (we launch this Aurora instance in Ireland for now), so this virtual machine did fail although storage is spread across 6 availability zones. I mean, though the data has copies and we didn't lost our data, but this particular machine is failed. Let's say we lost EU-WEST-1c as our availability zone, we need to automatically failover to another availability zone. The way to do this is to create an Aurora replica.

Go to create a Aurora replica. Select the Aurora instance you created just now, click Instance Actions -> create Aurora replica.

You need to choose the source database of this replica and give it an identifier as well. Normally you just need to select the same instance class with the source instance.

Publicly accessible - Yes

Availability zone - No preference. Amazon will automatically put it to a separate one to our primary instance.

Failover priority could be Tier 1. Tier 1 is the first place that the primary instance will fail over to.

Leave everything else as default and click launch.

When the replica becomes available, you can see the replication role of it is reader, and you cannot write to it.

You can see the Cluster Endpoint has been generated and it has made up this DNS end point name, and this is what you use in your connection strings for your applications in order to connect into the database.

You can see the Multi-AZ. It says 2 zones. If I add another Aurora replica of the primary instance, then it will say 3 zones etc. You can have more than 2 zones and you can have up to as many availability zones that within your Region as possible. So if you are in the US-EAST-1 region, you can have up to 4 zones.

Compare the primary instance with the replica. You can notice that the primary instance has Cluster Endpoint (DNS address for the cluster), and the replica has Instance Endpoint (DNS address for this particular instance). If the primary instance failed, the cluster DNS address is automatically failover to the instance end point, so you don't need to go in and update your connection strings, because Amazon handle all the failover. So always use the Cluster Endpoint when you are putting this into connection strings, instead of Instance Endpoint.

Select one of instances, go to Instance Actions -> Failover, you can actually do a failover. You can also Take Snapshot or Restore to Point in Time or Delete. When you delete the replica and the primary instance, the deleting completion of replica must happen before the deleting completion of the primary instance, because we can delete the cluster only when we have deleted the replicas.