There are many reasons an organization might choose Amazon Aurora over the Amazon Relational Database Service (Amazon RDS). Superior performance, greater scalability, and the ability to restart without losing cache are just a few. However, for those organizations who are already running an important application or Website on top of the RDS managed service, it can be a challenge to migrate from it to Aurora, despite the latter’s obvious benefits. After all, you can’t just take down a service that customers expect access to 24x7.
The best approach in these situations is replication. With this in mind, enter the newest feature from AWS: the ability to create an Aurora Read Replica from an RDS MySQL database instance. If you are already using RDS, you know that the managed service supports several database engines -- from PostgreSQL to SQL Server. However, it’s important to note that this new feature pertains specifically to MySQL. Given that, let’s examine this latest feature and then we’ll share our experience with how this could potentially benefit your organization.
Simply put, the new feature allows you to migrate from an Amazon RDS DB instance for MySQL to Amazon Aurora DB by creating an Aurora Read Replica. At a high level, users create a snapshot of the existing database instance and then use it as the foundation for a new Aurora Read Replica. With replication, the Read Replica is brought current and from here, users can turn the Aurora Read Replica into a standalone Aurora cluster and point the dependent application or Website at it.
Note that AWS reports that migration takes several hours per terabyte of data -- with replication running somewhat faster for InnoDB tables than for MyISAM tables and benefitting from the presence of uncompressed tables. The feature works for MySQL DB instances of up to 6 terabytes.
Moving to Amazon Aurora
Our AWS consulting team is a fan of Aurora as it combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Indeed, we recommended Aurora as part of the solution we worked with Rent-A-Center to build and deploy, and it has stood the test of time --and more importantly Black Friday.
Not everyone starts with Aurora, however, and we have many clients who would like to migrate from RDS to it, but have been inhibited by the always-on nature of the applications their database serves.
For example, we worked with an emergency communications provider that, as you would expect, has zero tolerance for downtime. This particular organization works in remote locations as well, alerting field service personnel to impending natural disasters like tornadoes. When people are depending upon your service to alert them of impending life and death situations, there really is zero room for unavailability. However, this organization might move to Aurora in the future as it would benefit from Aurora’s level of automated provisioning, patching, backup, recovery, failure detection and repair. In this case, the seamless, zero downtime migration to Aurora with read replica would be an ideal solution.
Another use case that proves interesting for the new Aurora read replica feature is a client of ours that is a popular brand that sells products for the home. Their environment is such that they must at regular intervals distill their data, sending it to QA. The process to dump and load the data to another database takes this organization one week. Read replica could be quite powerful here, allowing the brand to simply carve off of production and use it in QA whenever they like -- this while always having a production version of the database.
For more information on how your organization can best take advantage of AWS database services and ensure the continuous improvement of your database’s performance and ease management, please see the resources on our database page. And, please sign up below for our ongoing analysis of new AWS features, tips, tricks and use case stories of successful DevOps.