eWay Corp In our previous post on Amazon Aurora, we saw what Amazon Aurora is, features of AWS Aurora MySQL compatible edition, and several other valuable aspects of Aurora. You can read the post here. As a continuation to our previous post, we’ve written this blog focusing on migration of RDS for MySQL databases to Amazon Aurora. This post offers a step-by-step guide to this AWS Aurora migration.
But before diving into the migration process, let’s see why MySQL to Aurora migration is advantageous and what factors you need to consider before proceeding to migrate.
Migrate RDS for MySQL to Amazon Aurora
Although MySQL is the most widely used open-source database across the globe, the heavy lifting of backups, scaling, and high availability of MySQL databases is often found complex and/or time-consuming by many customers.
This is the chief reason why customers choose to shift their MySQL footprint to Amazon RDS for MySQL. With Amazon RDS, you get innovative features like high availability options and point-in-time recovery. Additionally, RDS for MySQL supports five read replicas for every source. This enables you to scale read workloads easily without the need of manually configuring and maintaining binary log (binlog) replication.
To achieve MySQL compatibility combined with the availability and performance of high-quality commercial databases, you can consider migrating your MySQL databases to Amazon Aurora. Aurora with MySQL compatibility lets you benefit from features like autoscaling replicas and fast database clones.
You’re also offered native integration with other AWS services like Amazon CloudWatch Logs and AWS Lambda.
Furthermore, Amazon Aurora offers increased durability by replication of data over 3 Availability Zones. Aurora can also scale to 15 Aurora Replicas, within latency that’s often less than 20 milliseconds.
Migrating from Amazon RDS for MySQL to Amazon Aurora
Like any other migration, there are several factors to consider here. These include:
- The source
- The target
- The client applications depending on the database to be migrated
- Business requirements related to availability during migration
During migration to Amazon Aurora’s MySQL edition, keep in mind that Amazon Aurora has wire-compatibility with MySQL 5.6 and 5.7.
This means, from an application standpoint, there’s no difference between Aurora 5.6 or 5.7 and MySQL 5.6 or 5.7. So, no changes are necessary in the existing application code for the migration process.
Although you don’t need to change the code in applications, you need to find a way of channeling applications to the new database. You can, of course, change the connection strings for all the applications, but it’s best to employ DNS for the job.
In the case of DNS, your database instance’s actual host name shouldn’t be used in your connection string. Rather, you can create a canonical name (CNAME) record pointing to your database instance’s host name. By doing this, you can change the endpoint to which the application points, in one single location, instead of tracking and modifying several connection string settings.
If you go for this approach, ensure that you pay attention to your CNAME record’s time to live (TTL) setting. In case this value is too high, then the host name that this CNAME points to might be cached for too long; if the value is too low, your client applications may face additional overhead as they’ll need to resolve this CNAME again and again. Although use cases differ, it’s good to start with a TTL of 5 seconds.
Steps to Migrate RDS for MySQL Databases to Aurora
The first step in migration of existing RDS for MySQL instance to an Aurora cluster is selecting the instance in Amazon RDS Management Console. Then, from Instance actions, select Create Aurora read replica.
Image source: aws.amazon.com
After selecting this option, you’ll need to specify several parameters which define the Aurora cluster. The master username and password for Amazon Aurora cluster is the same as that of the source instance.
After selecting this option, you’ll need to specify several parameters which define the Aurora cluster. The master username and password for Amazon Aurora cluster is the same as that of the source instance.
When the migration process has been started, a snapshot of the existing RDS for MySQL instance is created by Amazon RDS and the data from the snapshot is restored to the newly made Aurora cluster. This process can take several hours based on the source database size.
Image source: aws.amazon.com
Once Amazon Aurora cluster is created and the initial set of data is loaded in it, Amazon RDS sets up binlog replication from RDS for MySQL instance to Aurora cluster. When the binlog replication has been set up and replication starts, it’s recommended to monitor the CloudWatch metric of Aurora Binlog Replica Lag on Aurora cluster.
Image source: aws.amazon.com
Although you can get a high-level view of binlog replica lag with CloudWatch, a more precise measurement can be obtained by logging in to the newly made Aurora cluster. You can do this by using the MySQL client and running the command show slave status\G. A lot of helpful information is returned by this command; however, the specific metric that we’re looking for is Seconds_Behind_Master. Once this metric becomes 0, the newly created Aurora cluster is synched with the original RDS for MySQL instance.
When this synch is reached, you should stop writes on the RDS for MySQL instance. You now start writing to the new Aurora cluster. Doing this with RDS for MySQL requires you to modify the parameter group that’s assigned to your instance.
The setting read_only has a default value of {TruelfReplica}. You’ll need to explicitly set the value to 1, which shows the instance is in the mode of read-only. This parameter consists of a dynamic apply type, meaning that its setting comes into effect instantly and doesn’t need a reboot.
Image source: aws.amazon.com
The source RDS for the MySQL instance is in the read-only mode now. You’ll need to check the Seconds_Behind_Master metric at this point once again to make sure all the binlogs have been applied.
Then, your Aurora read replica needs to be promoted to a writer. You can do this by selecting the target Amazon Aurora cluster and then choosing Promote read replica from Instance actions. Once it’s selected, the process takes a few minutes to complete. Change the CNAME that the applications refer to at this point, as discussed earlier.
To learn about completion of the process, check Recent events for the new Aurora cluster, as displayed below.
Image source: aws.amazon.com
Wrap Up
Following this AWS Aurora migration guide, you can migrate RDS for MySQL instance to an Amazon Aurora cluster with almost zero downtime. If you’re not a pro at MySQL to Aurora migration, start planning it with the help of a reliable AWS database migration service. eWay Corp specializes in database migration from on premise to AWS cloud and can help you successfully migrate MySQL to Aurora.
eWay Corp is a leading IT services company based in Des Moines, Iowa. We offer 360-degree technology solutions including, but not limited to, cloud services, hosting, managed services, and web development. Let us help you boost your business with our technical expertise!
