Migration from Aurora Serverless v2 to Standalone RDS MySQL

Your migration plan from Aurora Serverless v2 to standalone RDS MySQL instances is generally sound, but there are a few considerations and best practices to keep in mind:

1. AWS DMS with Aurora Serverless v2: AWS DMS is compatible with Aurora Serverless v2 as a source. However, be aware that Aurora Serverless v2 can scale its capacity, which might affect the performance of the DMS tasks. Ensure that your Aurora cluster has enough capacity to handle both your application load and the DMS replication load.

2. Running multiple DMS tasks concurrently: Yes, it's generally okay to run multiple DMS tasks concurrently, one for each database. This approach can help parallelize the migration process. However, be mindful of the following:

• Monitor the source Aurora cluster's performance to ensure it can handle the load from multiple concurrent DMS tasks.
• Consider staggering the start times of your DMS tasks to avoid overwhelming the source database all at once.

3. Clean and low-downtime cutover: To ensure a clean cutover with minimal downtime:

• Use the AWS DMS change data capture (CDC) feature to keep the source and target databases in sync during the migration.
• Before the final cutover, verify that the replication lag has reached zero and all changes have been applied to the target.
• Implement a brief application freeze during the cutover to ensure no data loss.
• Have a rollback plan ready in case of unexpected issues during the cutover.

4. Additional considerations:

• Verify that all database objects, including stored procedures, triggers, and views, are correctly migrated. DMS might not handle all of these automatically.
• Test the migration process thoroughly in a non-production environment before attempting it on your production databases.
• Consider using native MySQL tools like mysqldump for schema migration if you encounter any issues with DMS.
• Monitor the performance of your new RDS instances after migration to ensure they can handle your workload, as you're moving from a scalable serverless solution to fixed-size instances.
• Plan for potential differences in connection handling between Aurora Serverless v2 and standalone RDS instances.

By following these best practices and considerations, you should be able to achieve a successful migration from your Aurora Serverless v2 cluster to standalone RDS MySQL instances with minimal downtime.
Sources
DMS migration - Amazon Aurora MySQL Migration Handbook
Migrating a MySQL Database to RDS for MySQL or Aurora MySQL - Database Migration Guide

Hello There,

I understand that you are attempting to migrate multi-database Aurora Serverless v2 (MySQL v8.0 compatible) cluster to standalone RDS Instances for cost optimisation and you are looking for some insights on the concerns/queries you have.

==============================

Firstly, For the best practices while using the Aurora Serverless v2 as source for your Data Migration Service setup. For your Aurora Serverless v2 capacity configuration, make sure your ACU (Aurora capacity units) is set to high enough to handle the load from DMS, for large migrations, do calculate your ACUs based on number of tables being migrated, data volume and migration speed required.

Also, Kindly enable the binary logging (binlog) for MySQL-compatible Aurora cluster. And, in general, you can always go through the following AWS DMS documentation for using a MySQL-compatible database as a source for DMS.

[+] : https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html

Coming to your next query, Yes, you can run multiple DMS tasks concurrently from the same Aurora Serverless v2 source and do consider to monitor the source load impact as multiple tasks will increase the load on the source cluster. Hence, set the appropriate maximum ACU limit to auto-scale when needed.

For clean and low-downtime cutover, Do monitor appropriate DMS metrics such as CDCLatencySource, CDCLatencyTarget, lag in general between the source and target(s) meaning validate the data consistency between your source cluster and target instance, recommended to schedule the cutover during low-traffic period while ensuring writes are stopped on the source database. Further, you are update the applications strings and verify the application performance and functionality.

——————————

Additional References:

——————————

[+] : https://docs.aws.amazon.com/dms/latest/userguide/CHAP_BestPractices.html

[+] : https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html

[+] : https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html