Migrating from Amazon RDS for MySQL

If you are migrating from an RDS MySQL DB instance, the recommended approach is to use the Aurora Read Replica feature for a near-zero downtime migration.

Aurora Read replica is a fully managed, point-and-click feature that is available through the AWS Management Console or using AWS CLI. It is the simple and fast method to migrate to Aurora MySQL with minimal downtime.

If you can afford downtime, the recommended approach is to use RDS Snapshot migration. This is a fully managed, point-and-click feature that is available through the AWS Management Console. You can use it to migrate an RDS MySQL DB instance snapshot into a new Aurora DB cluster.

For more information about the snapshot migration feature, refer to Migrating data from a MySQL DB instance to an Amazon Aurora MySQL DB cluster in the Amazon Aurora User Guide.

This section provides ideas for projects that use the Aurora read replica and snapshot migration feature. The list-style layout in our example instructions can help you prepare your own migration checklist.

Migrating from a RDS for MySQL to Aurora MySQL using a Read Replica

When you create an Aurora read replica of a MySQL DB instance, Amazon RDS creates a DB snapshot of your source MySQL DB instance. Amazon RDS then migrates the data from DB snapshot to the Aurora read replica. After the data from the DB snapshot has been migrated to the new Aurora MySQL DB cluster, Amazon RDS starts binary log replication between your MySQL DB instance and the Aurora MySQL DB cluster. If your MySQL DB instance contains tables that use storage engines other than InnoDB, or compressed row format then RDS will convert the tables in to Aurora MySQL compatible format as a part of migration. Depending on the size of the table, conversion and migration time may vary.

You can speed up the process of creating an Aurora Read Replica by altering those tables to use the InnoDB storage engine and dynamic row format in the source instance before you create your Aurora Read Replica.

Note

You can only create an Aurora MySQL 3 with MySQL 8.0 compatibility read replica DB cluster of an Amazon RDS for MySQL running 8.0.23 or lower version.

Reducing the amount of space required to migrate data into Amazon Aurora

When you migrate to Aurora MySQL using Read Replica method or using snapshot of a MySQL DB instance, Aurora uses an Amazon Elastic Block Store (Amazon EBS) volume to format the data from the snapshot before migrating it. There are some cases where additional space is needed to format the data for migration. The two features that can potentially cause space issues during migration are MyISAM tables and using the ROW_FORMAT=COMPRESSED option. If you are not using either of these features in your source database, then you can skip this section because you should not have space issues. During migration, MyISAM tables are converted to InnoDB and any compressed tables are uncompressed. Consequently, there must be adequate room for the additional copies of any such tables.

The size of the migration volume is based on the allocated size of the source MySQL database that the snapshot was made from. Therefore, if you have MyISAM or compressed tables that make up a small percentage of the overall database size and there is available space in the original database, then migration should succeed without encountering any space issues. However, if the original database would not have enough room to store a copy of converted MyISAM tables as well as another (uncompressed) copy of compressed tables, then the migration volume will not be big enough. In this situation, you would need to modify the source Amazon RDS MySQL database to increase the database size allocation to make room for the additional copies of these tables, take a new snapshot of the database, and then migrate the new snapshot.

When migrating data into your DB cluster, observe the following guidelines and limitations:

• Although Amazon Aurora supports up to 128 TiB of storage, the process of migrating a snapshot into an Aurora DB cluster is limited by the size of the Amazon EBS volume of the snapshot, and therefore is limited to a maximum size of 64 TB.

Non MyISAM tables in the source database can be up to 16 TB in size. However, due to additional space requirements during conversion, make sure that none of the MyISAM and compressed tables being migrated from your MySQL DB instance exceed 8 TB in size. For more information, refer to Migrating Data from an Amazon RDS MySQL DB Instance to an Amazon Aurora MySQL DB Cluster.

You might want to modify your database schema (convert MyISAM tables to InnoDB and remove ROW_FORMAT=COMPRESSED) prior to migrating it into Amazon Aurora. This can be helpful in the following cases:

• You want to speed up the migration process.

• You are unsure of how much space you need to provision.

• You have attempted to migrate your data and the migration has failed due to a lack of provisioned space.

Ensure that you are not making these changes in your production Amazon RDS MySQL database but rather on a database instance that was restored from your production snapshot. For more details on doing this, refer to Reducing the Amount of Space Required to Migrate Data into Amazon Aurora in the Amazon Aurora User Guide.

The naming conventions used in this section are as follows:

• Source RDS DB instance refers to the RDS MySQL DB instance that you are migrating from.

• Target Aurora DB cluster refers to the Aurora DB cluster that you are migrating to.

Migrating with near-zero downtime

AWS recommends using Aurora read replica approach to migrate from a MySQL DB instance running versions MySQL 5.6, 5.7, 8.0.23 or lower to Aurora MySQL DB cluster with minimal downtime. You can perform this using AWS Management console or AWS CLI.

The high-level procedure for migrating to Amazon Aurora from RDS MySQL DB instance is as follows:

1. On the source RDS DB instance, ensure that automated backups are enabled.

2. Create an Aurora Read Replica from the source RDS DB instance.

3. Once the Aurora DB cluster is available, wait for the replication to catch up, that is, for the replication lag to reach zero.

4. Begin cutover by stopping all write activity against the source RDS DB instance. Application downtime begins here.

5. Verify that there is no outstanding replication lag, and then promote Aurora read replica.

6. Once the cluster successfully promoted, complete cut-over by resuming write activity on Aurora MySQL DB cluster. Application downtime ends here.

   For a detailed description of this procedure, refer to Migrating data from a MySQL DB instance to an Amazon Aurora MySQL clyster by using an Aurora read replica.

Migrating with downtime

When migration downtime is acceptable, you can use the following high-level procedure to migrate an RDS MySQL DB instance to Aurora MySQL:

1. Stop all write activity against the source RDS DB instance. Database downtime begins here.

2. Take a snapshot of the source RDS DB instance.

3. Wait until the snapshot shows as Available in the AWS Management Console.

4. Use the AWS Management Console to migrate the snapshot to a new Aurora DB cluster. For instructions, refer to Migrating Data to an Amazon Aurora DB Cluster in the Amazon RDS User Guide.

5. Wait until the snapshot migration finishes and the target Aurora DB cluster enters the Available state. The time to migrate a snapshot primarily depends on the size of the database. You can determine it ahead of the production migration by running a test migration.

6. Configure applications to connect to the newly created target Aurora DB cluster instead of the source RDS DB instance.

7. Resume write activity against the target Aurora DB cluster. Database downtime ends here.

   For a detailed description of this procedure, refer to Replication between Aurora and MySQL or between Aurora and another DB cluster in the Amazon Aurora User Guide.

Migrating from Amazon RDS for MySQL to higher version Aurora MySQL

There are times you may want to upgrade to higher version as a part of the migration process. To migrate from RDS MySQL 5.7 to Aurora MySQL 3, you can achieve it in one of the following ways:

• Migrate RDS for MySQL 5.7 to Aurora MySQL 2 version using Aurora read replica method. After the read replica DB cluster is created, and it has caught up with all the changes (make sure the replication is running, and the replica lag is zero). Take a snapshot of Aurora MySQL 2 and upgrade the snapshot to Aurora MySQL 3.

• Upgrade the RDS for MySQL 5.7 snapshot to RDS for MySQL 8.0 (MySQL version 8.0.23 and below) instance, take a snapshot of the MySQL 8.0 DB instance, and then restore the snapshot to Aurora MySQL version 3.

• You can manually set up binary log replication for near-zero migration downtime with this method. For details, refer to Replication between Aurora and MySQL or between Aurora and another Aurora DB cluster (binary log replication)

For more information about upgrading RDS MySQL engine versions, refer to Upgrading the MySQL DB Engine. For Aurora MySQL, refer to Upgrading Amazon Aurora MySQL DB Clusters.