What is Amazon Aurora?
Amazon Aurora is a completely manageable relational database engine which is compatible with PostgreSQL and MySQL.
MySQL and PostgreSQL have both the dependability and the speed of high-end commercial databases combined with the easy-operation and cost-efficiency of working with open-source databases.
What are the advantages of Amazon Aurora?
Amazon Aurora allows you to utilize tools, apps and codes used daily with already existing PostgreSQL and MySQL databases.
Amazon Aurora is capable of delivering with specific workloads up to 5 times the throughput of MySQL.
Amazon Aurora is capable of delivering with specific workload up to 3 times the throughput of PostgreSQL with not need for any alterations to a number of already existing apps.
What are the features of Amazon Aurora?
Amazon Aurora has a storage subsystem which is high-performing and available.
Underlying storage is capable of automatically growing as required, to a total of 64 TiB.
Amazon Aurora’s PostgreSQL- and MySQL-compatible database engines are designed specifically for the sake of benefiting from fast-distributed storage.
Amazon Aurora is considered part of the managed database service which is Amazon RDS.
Amazon Aurora standardizes and automates database replication and clustering, and they are mainly considered one of the greatly complex parts of database administration and configuration.
Amazon RDS is also a web service providing a simpler way for operating, setting up and scaling a cloud’s relational database.
How is Amazon Aurora similar to the standard PostgreSQL and MySQL engines found in RDS?
- Amazon Aurora is selected as a DB engine option upon the set-up of a new database server using RDS.
- Amazon Aurora is capable of benefiting from the related RDS features for administration and management. Aurora uses the Amazon RDS AWS Management Console interface, AWS CLI commands, and API operations to handle routine database tasks such as provisioning, patching, backup, recovery, failure detection, and repair.
- Aurora management operations typically involve entire clusters of database servers that are synchronized through replication, instead of individual database instances. The automatic clustering, replication, and storage allocation make it simple and cost-effective to set up, operate, and scale your biggest PostgreSQL and MySQL deployments.
- Data may be brought from RDS for PostgreSQL and RDS for MySQL into Aurora through the creation and restoration of snapshots, otherwise trough the set-up of 1-way replication. Push-button migration tools may be utilized for the sake of converting an already existing RDS for PostgreSQL and RDS for MySQL apps to Aurora.
How are Instance Endpoints used?
A general process for utilizing instance endpoints is for the sake of diagnosing performance and capacity problems that may inflict a specific instance found in your Aurora cluster.
When you are connected to an instance, you will be able to study its status metrics, variables and other information about it. By such an action, you will be able to learn and keep track of the processes for this specific instance and to know the different actions happening to it which differ from what’s taking place with other instances found in this cluster.
For more complex use cases, you will be able to configure a couple of DB instances in a different way than of the remaining others. For such a use case, you will need to utilize the instance endpoint for directly connecting to an instance which is larger, smaller or includes differing characteristics than those of the other instances.
Additionally, you will need to get failover priority set up in order to make this unique DB instance the final choice for taking over as the main primary instance. It is better for you to utilize custom endpoints in the place of the instance endpoint which is in those mentioned type of cases. This is capable of simplifying high availability and connection management while you are adding extra DB instances to the selected cluster.
Every single DB instance found in an Aurora cluster includes a unique built-in instance endpoint, with a name and attributes that are going to be managed through Aurora. It’s not possible to create, modify or either delete such a type of endpoint.
How do Aurora Endpoints Perform in High Availability?
Clusters that are in need of high availability, should be used with the:
– “Writer” endpoint for read and write connections
– “Reader” endpoint for read-only connections
The above-mentioned connections are capable of managing DB instance fail-over in a much efficient way than that of instance endpoints.
Instance endpoints tend to be connected to a selected DB instance found in a specific DB cluster, needing of the logic in your app to pick another endpoint in case the DB instance turns unavailable.
When a primary DB instance of the DB cluster ends up failing, Amazon Aurora will directly fail over to another new primary DB instance, through one of the following ways:
– Creating another new primary DB instance
– Promoting an already existent Aurora Replica to another new primary DB instance
Once failover takes place, you are capable of doing one of the following options:
– Utilizing the cluster endpoint for the sake of reconnecting to the newly created or the newly promoted primary DB instance
– Utilizing the reader endpoint for the sake of reconnecting to 1 of the Aurora Replicas that are found in the DB cluster
As a fail-over takes place, reader endpoint may actually direct connections to the newly chosen primary DB instance of a DB cluster for a small period as soon as a selected Aurora Replica gets promoted to the newly chosen primary DB instance.
In case you are the one who designs the app logic for the sake of managing connections to instance endpoints, you are then capable of either programmatically or manually discovering the formulated set of available DB instances that are found in the DB cluster. Which will give you the chance be the one who confirms their instance classes upon fail-over and then start a connection to the right instance endpoint.