If you have mission-critical workloads running on MYSQL database, you may be looking for ways to migrate to AWS with minimal to near-zero downtime. This provides a solution for migrating your MYSQL database to AMAZON S3 using the Ongoing Replication (Change Data Capture Task Settings ) with AWS Database Migration Service (AWS DMS) to minimize downtime. This method is useful when you have to migrate the database code objects, including views, stored procedures, and functions, as part of the database migration.

Overview:

The solution uses a MySQL database considered as the on-premises source database and Amazon S3 as the target database for migration.

as described in the following diagram. The initial stage is required to apply ongoing data changes to Amazon S3 and uses AWS DMS to replicate data changes from the on-premises database (MYSQL) to Amazon S3.

DMS Diagram

Implementation steps:

Stage uses AWS DMS for ongoing data changes:

1. Create the AWS DMS replication instance and endpoints with the source and target databases.

1. Create an AWS DMS task for continuous replication from the source to target database.
2. Monitor the task for ongoing replication and cutover the application

1. Set Up Source and Target Endpoints:

The first step is to set up your source and target endpoints. The source, presumably, already exists, but there may be steps to take before the migration begins, especially if you’re syncing changes on an ongoing basis or changing database engines. Check the online DMS documentation for any setup tasks you need to complete first, which may include installing drivers or the Schema Conversion Tool (an application used to translate your current database onto a new engine).

Preparing your target database usually requires creating a user with the highest privileges and access to the database that AWS DMS can connect with. When the source and target are set up, create a Source Endpoint and a Target Endpoint through the AWS console in DMS.

2. Create a Replication Instance

The Replication Instance performs the migration between the two endpoints. It can be difficult to determine how big the replication instance can be, but the size can easily be changed through the console. Monitoring can be set up through AWS CloudWatch to tell you how much of the instance’s CPU and network bandwidth is being used. When creating a replication instance, set it up in the same VPC as the source or target instance. And if either instance isn’t in the VPC, be sure to mark the replication instance as Publicly Accessible.

3. Configure Migration Tasks

Migration Tasks define the migration itself – the source, replication instance, target, and various options.

Most of the task fields are straightforward, but there are a few to look out for:

• Include Large Object (LOB) columns in replication – LOBs can be migrated using DMS, but the default cut-off size is 64 KB. Anything larger will be truncated. Review your database schema and values to check if this value needs to be adjusted.
• Table Mappings – This section allows you to include or exclude tables based on selection rules, which is especially handy if you’re dividing a large database into smaller databases for microservices. Transformation rules are also useful for updating outdated table or column names.

• Control Table Settings – Control tables provide information about the migration itself, including the replication status, tables that were suspended during the migration, and the replication history. Enable each table to help debug failed migrations.

Conclusion

Amazon’s DMS is a great tool which makes it easier to migrate databases, especially large ones, from an existing server into the cloud AWS DMS migrate some of that complexity. The step-by-step guides that I provide in this post help you get hands-on experience migrating MYSQL to Amazon S3 using AWS DMS With Ongoing Replication (CDC). You can follow similar steps to migrate to and from other supported database engines.