Migrating Amazon RDS MySQL 8.0.35 to Amazon Aurora MySQL: What You Need to Know

If you’re using Amazon RDS for MySQL 8.0.35, you already enjoy the benefits of a managed database service, such as automated backups, easier maintenance, and less manual work compared to running MySQL yourself. But as applications grow, you start to need more performance, faster scaling, and stronger high availability. That’s when Amazon Aurora MySQL-Compatible Edition becomes a great option.

Amazon Aurora is still MySQL at its core, so your applications don’t need big changes. But under the hood, it’s built on a cloud-native storage system that makes it faster, more resilient, and easier to scale than standard Amazon RDS MySQL.

Pre-Migration Assessment

Before you begin with the actual cloud migration, it’s important to do a pre-migration assessment. A few pre-checks done up front can save you from unexpected surprises later. Here are the key things to look at before moving from Amazon RDS MySQL 8.0.35 to Amazon Aurora MySQL-Compatible Edition.

1. Check Version Compatibility

Since you’re on Amazon RDS MySQL 8.0.35, you’ll need to use Amazon Aurora MySQL 3.x, which is the only Amazon Aurora major version built for MySQL 8.x compatibility, as Amazon Aurora doesn’t support every MySQL version. This ensures your schema, queries, and stored procedures continue to work as expected.

But it is still recommended to review the latest Amazon Aurora release notes to confirm your application’s specific needs, like supported features, security patches, and known issues.

2. Backups and Logging

Ensure to have safety backups.

• Take a manual snapshot of your source Amazon RDS MySQL instance.
• Double-check that automated backups are enabled and that you’ve actually tested restoring from one.

3. Review Feature Compatibility

Amazon Aurora MySQL aims to stay compatible with MySQL, but it isn’t identical. One key difference is that it works exclusively with the InnoDB storage engine. That means if your database still uses MyISAM tables, you’ll need to convert them before migrating. Also, some MySQL system functions and configuration parameters may behave differently in Amazon Aurora.

That’s why it’s worth taking the time to review your database setup for things like features, triggers, stored procedures, and custom configurations, to make sure nothing depends on functionality that Amazon Aurora doesn’t support.

4. Test in a Staging Environment

Test application interactions with Amazon Aurora in a staging environment to ensure compatibility. This step helps you confirm:

• Queries run without errors.
• Application behavior is consistent.
• Performance meets expectations.

Catching issues in staging is much easier than discovering them mid-migration in production.

5. Plan for Downtime

Even with replication-based approaches, there is always a cutover step where you switch your application. That usually required some downtime. So plan for a realistic maintenance window and testing immediately after cutover to confirm everything is working.

Migration Approaches

Approach 1: Using an Amazon Aurora Read Replica

Using this method, you create an Aurora MySQL Read Replica of your current RDS MySQL primary instance to migrate from RDS MySQL 8.0.35 to Aurora. Here's how it works:

• By using your current Amazon RDS MySQL 8.0.35 primary instance, create an Aurora MySQL read replica (targeting Aurora MySQL 3.x). Make sure it runs in the same AWS Region.
• Allow some time for AWS to sync data automatically using MySQL binlogs, and keep monitoring the replication lag in AWS CloudWatch.
• Promote the Amazon Aurora read replica to a stand-alone Aurora cluster once the replication lag is negligible or zero. Remember this is a one-way operation as the original RDS instance and replicas won’t be linked after this step.
• In the newly promoted Aurora cluster, create an Aurora reader (read replica) to maintain your high-availability setup and handle read traffic.
• Update your applications and any connected tools (like Debezium) to point to the Aurora writer endpoint for writes and the reader endpoint for read-only workloads.
• Test your applications and queries to confirm everything works as expected. Ensure to check latency, replication, triggers, and stored procedures.
• Monitor Aurora performance using CloudWatch metrics and logs. If required, you can make parameter adjustments.
  After successful validation and observation, decommission the old Amazon RDS MySQL primary and replicas to avoid unnecessary costs.

Key Considerations:

• Plan the cutover window and perform cutover only after confirming that replication lag is at zero.
• Expect a short downtime during the cutover, so schedule a proper maintenance window.
• Make sure your application works correctly with Amazon Aurora’s features before making the switch.
• Promoting an Amazon Aurora Read Replica to a standalone cluster is a one-way operation. After the promotion, the original Amazon RDS
• MySQL instance and its replicas will not be part of the new Amazon Aurora cluster.
• The Amazon RDS primary and the Aurora replica must both be in the same AWS Region.

Approach 2: Binlog-Based Replication

Since AWS Blue/Green Deployments don’t support cross-engine migrations (like RDS MySQL to Aurora MySQL), this method using binlogs is the next best option, as it's based on the general concept of Blue/Green Deployments.

This method follows the same idea as a Blue/Green deployment, where one environment stays live (Blue) while the new one (Green) is synced in the background. Here’s how it works:

• Create a new Amazon Aurora cluster (Aurora MySQL 3.x) in the same Region.
• Enable binary logging on your Amazon RDS MySQL instance if it’s not already enabled.
• Set up replication from Amazon RDS MySQL to Aurora by configuring Aurora as a replica of your RDS instance using the binlogs. This ensures all ongoing changes from Amazon RDS are applied to Aurora.
• Monitor replication lag closely and keep the Aurora cluster in sync until you’re ready to switch.
• When you decide on a cutover window, stop writes to the Amazon RDS MySQL instance, wait for Aurora to catch up (lag = 0), and then point your applications to the new Aurora cluster.

Key Considerations:

• This method requires manual setup and monitoring of replication.
• Cutover still requires downtime for switching applications.

Note: Although AWS DMS is an alternative option, it’s not the best fit in this case. Since this is a homogeneous migration, using DMS would only add extra cost and complexity. 

Impact of Migration in terms of Performance, Stability, and Cost

1. Performance and Stability:

• Amazon Aurora offers up to five times the throughput of a standard MySQL database running on the same hardware.
• Aurora automatically scales storage in increments of 10 GB as you grow your database, up to 128 TB.
• Your data is copied six times across three Availability Zones, so it stays safe even if a disk or an entire AZ fails.
• Because of its replication, Amazon Aurora can automatically recover from a failure in less than 30 seconds, so your downtime is minimal.
• Amazon Aurora continuously checks its storage for errors and automatically repairs any bad blocks or disks.

All of these features make Amazon Aurora faster and more reliable for critical workloads than a traditional Amazon RDS MySQL application.

2. Cost:

There are no upfront costs or long-term licenses. Amazon Aurora works on a pay-as-you-go model. You are billed hourly for all database instances you run, in addition to storage and I/O costs (based on your pricing plan).

The actual cost depends on your workload, especially how many I/O operations your application performs and how often it reads from storage.

Amazon Aurora gives two pricing options:

• Amazon Aurora I/O-Optimized – This is best for I/O-heavy workloads like payments, eCommerce, and financial systems. You only pay for compute and storage, with no extra I/O charges. For very busy databases, this can cut costs by up to 40%.
• Amazon Aurora Standard – This is a better fit for low to moderate I/O workloads. In this model, you pay for compute, storage, and each I/O request, which often works out cheaper if your app isn’t very I/O-intensive.

Conclusion

Migrating from Amazon RDS MySQL 8.0.35 to Amazon Aurora MySQL-Compatible Edition 3.x is not a task that should be rushed. Proper planning is essential, especially in terms of version compatibility and your chosen migration method. In most circumstances, using replication or a snapshot will be a good option, but if you cannot use one of these options because of version differences between the two versions, a logical dump and restore will be a trusted and safe option.

Note:

• It is strongly recommended to test and validate your selected approach in a staging or non-production environment before deploying to a production environment. 
• Ensure you have proper backups, and have logging enabled to assist in troubleshooting and rollback if needed.
  It is advised to schedule your cutover during a maintenance window to minimize the impact of downtime on your users.

Planning a cloud database migration?
CloudKeeper supports organizations at every stage — from cloud migration planning and architecture design to seamless implementation and ongoing optimization. Book a call today with our cloud migration expert!