Why Use Amazon Aurora?
- Aurora is MySQL and PostgreSQL compatible. This implies that an Aurora cluster may be created as a MySQL (5.6 OR 5.7) database instance or a PostgreSQL database instance. Open source MySQL and PostgreSQL databases may be migrated to Aurora.
- With its performance and high availability, Aurora brings the advantages of commercial databases to open source databases.
- Aurora MySQL is 5x faster than a non-Aurora MySQL database instance. Aurora PostgreSQL is 3x faster than a non-Aurora PostgreSQL database.
- Aurora is a RDS managed database, which implies that most of the administration tasks including provisioning, setup, patching, and backups on S3 are automated.
- Aurora provides replication across three availability zones. Failure of a single Availability zone does not cause the database to become unavailable. Up to 15 read replicas may be added across the three zones.
- Aurora is fault-tolerant. Aurora replicates 6 copies of a database across three availability zones. Instance failover takes less than 1/2 minute.
- Aurora auto scales up to 64 TB per instance.
- Aurora is integrated with the other AWS services including CloudWatch, VPC, and IAM.
In this article, we shall create an Amazon Aurora cluster. This article has the following sections:
- Setting the Environment
- Creating an Aurora Cluster
- Configuring Accessibility to the Aurora Cluster
Open AWS RDSin a Web browser. Click the Get Started Now button, as shown in Figure 1.
Figure 1: AWS RDS >Get Started Now
In Select engine, select the Amazon Aurora engine, as shown in Figure 2.
Figure 2: Selecting Aurora Engine
Select from one of the three supported editions: MySQL 5.6-compatible, MySQL 5.7-compatible, and PostgreSQL compatible. MySQL 5.7-compatible is selected, as shown in Figure 3. Aurora is not eligible for the free-tier. Click Next.
Figure 3: Selecting Aurora Edition
First, specify the DB details, as shown in Figure 4. Select the DB Instance class. For a multi-availability zone deployment, select the Create Replicas in Different Zone option.
Figure 4: Specify DB details
Scroll down for Settings, as shown in Figure 5. Specify a DB instance identifier (mysqldb). Specify a Master username and Master password. The MySQL root user is not made available and its password is not settable. Click Next.
Figure 5: Aurora Settings
Configure advanced settings for Network & Security, Database options, Authentication, Encryption, Failover, Monitoring, and Maintenance. In Network & Security, select a VPC and Subnet group (see Figure 6). Public accessibility must be set to Yes.
Figure 6: Selecting VPC, Subnet group, and configuring Public Accessibility
Scroll down for more advanced settings. For Availability zone, keep the default setting of No preference, as shown in Figure 7. Select Create new VPC security group. For a Multi-AZ cluster, the availability zones are selected automatically.
Figure 7: Selecting Availability Zone as No preference
For Database options, specify a DB Cluster Identifier (aurora-mysql) and specify a Database name (mysqldb), as shown in Figure 8. Keep the Database port as the default value of 3306. Keep the default settings for DB parameter group, DB Cluster parameter group, and Option group.
Figure 8: Database options
For IAM DB authentication, select Disable because we won't be using IAM authentication; we have created the Aurora cluster as the root user. For Encryption, select Disable and for Failover, select No preference, as shown in Figure 9.
Figure 9: Authentication, Encryption, and Failover settings
For Monitoring, select Disable enhanced monitoring and, for Maintenance, select Enable auto minor version upgrade, as shown in Figure 10. The auto minor version upgrades occur during a Maintenance window for which the setting of No preference is selected.
Figure 10: Monitoring and Maintenance settings
Click on Launch DB Instance (see Figure 11).
Figure 11: Launch DB Instance
As the message shown in Figure 12 indicates, the DB instance starts to get created. Click View DB Instance Details.
Figure 12: DB instance being created
The aurora-mysql cluster gets created, as shown in Figure 13. The Status is listed as "available" and the Instances count is 2.
Figure 13: Aurora Cluster
In the Instances table, two instances are listed, as shown in Figure 14. The mysqldb instance is a read-write instance that is used to create new database objects. The mysqldb-us-east-1c is a read-only replica created in a different availability zone.
Figure 14: Aurora Instances
Scroll the Instances table to the right. The mysqldb instance is listed in the Replication role column as writer, and the mysqldb-us-east-1c instance is listed as reader, as shown in Figure 15.
Figure 15: Replication role
To find details about the mysqldb instance, click the link (see Figure 16).
Figure 16: mysqldb instance link
The Summary for the mysqldb instance gets displayed, as shown in Figure 17.
Figure 17: Summary for mysqldb Instance
The database metrics charts for CPU Utilization, DB Connections, Freeable Memory, Network Receive Throughput, Network Transmit Throughput, and Active Transactions are displayed, as shown in Figure 18.
Figure 18: Metrics Graphs
As shown in the Connect section, the Security group Inbound rule is set to a specific CIDR. To access database instance from JDeveloper on a local machine, we need to modify the Inbound rule. Click the Security group link, as shown in Figure 19.
Figure 19: Security group link
Select the Inbound tab and click Edit to modify the inbound rule, as shown in Figure 20.
Figure 20: Security group>Inbound>Edit
In Edit inbound rules, modify Source to Anywhere and click Save (see Figure 21).
Figure 21: Modifying Inbound rules
The Inbound rules get modified, as shown in Figure 22.
Figure 22: Modified Inbound rules
In this article, we introduced Amazon Aurora and the benefits it offers. We started by creating an Aurora cluster compatible with MySQL database and configuring accessibility to the cluster.