Amazon Aurora is a database engine that uses tables and principles to bring together reliability and speed of top-notch commercial databases and open source databases that are simple and cost-effective.
With Aurora, you get 5× of MySQL performance without having to alter MySQL applications. It is in the same way that Aurora PostgreSQL gives 3× the performance of PostgreSQL.
The management of your Aurora databases is handled by Amazon RDS. It takes care of various tedious tasks like backup & recovery, provisioning, breakdown detection, and repair.
For each of these database instances you utilise, there is a certain monthly charge incurred. You don’t need to commit to any long-term agreements or pay an upfront cost.
Aurora comes with a storage system that doesn’t get faulty, is distributed, can heal itself and it auto-scales up to 64TB for every database instance. Expect availability of up to 15 low-latency read duplicates, instant recovery, and backup to Amazon S3.
How to Migrate from MySQL to Aurora and Vice Versa
There are several ways you can do this:
- Firstly, you can utilise the common mysqldump utility that exports information from MySQL and mysqlimport utility to import the data to Aurora and vice versa.
- There is also another option where you use Amazon RDS’s database Snapshot migration tool to move an RDS MySQL DB Snapshot to the Aurora with the help of AWS Management Console. You will be able to successfully migrate in one hour, although the time span is fully dependent on the data size.
- Also, if you wish to migrate from PostgreSQL to Amazon Aurora, simply use the pg_dump utility to transfer data from the former and pg_restore utility to move it to the latter and vice versa. Amazon RDS’s Db Snapshot feature can help in moving an RDS PostgreSQL 9.6 DB Snapshot to Aurora with the help of AWS Management console.
What are IOs and How DO You Calculate Them?
These are input/output operations that the Aurora database performs against its virtual storage layer. Each read operation is considered as an IO.
These reads are issued by Aurora DB engine with the aim of getting database pages that are missing in the buffer cache. In Aurora MySQL, every database page is approximately 16KB while that in Aurora PostgreSQL is 8KB.
Originally, Aurora was meant to get rid of unwanted IO operations, which would reduce costs and make sure that the read/write traffic has enough resources. Write IOs only get used when transferring transaction log records to the storage area with the aim of producing write durable, and they are usually counted in 4KB units.
To view the number of IOs the Aurora instance is using up, simply refer to the AWS console and to see your IO usage, visit the RDS console section.
Amazon Aurora Serverless
In 2017, this service was introduced. It is specially designed for those workloads that are very variable and bound to change as it gives you the freedom to pay for the database resources you utilise on a second-by-second frequency. The model sits on a clean differentiation of storage and processing that is an inseparable part of the Aurora structure.
Rather than selecting your database instance size beforehand, you come up with an endpoint for your preferred smallest and biggest capacity and then send queries to the endpoint. This endpoint tends to be simply a proxy that directs all the queries to swiftly scaled database resources.
Image source: https://aws.amazon.com