Database Migration Made Easy with AWS DMS
As organizations are preparing to relocate their database workloads to AWS, they also feel the need for changing the database engine. There can be various reasons for this; moving to the open-source engine to reduce cost, policy changes etc. For organizations, whose workloads are on AWS, and want to change database engine, AWS DMS works as a solution for them. Amazon Web Services (AWS) Database Migration Service (DMS) allows migrating data from one database to another.
AWS Database Migration Service tasks require at least a source, a target, and a replication instance. Your Source is the database you wish to move data from and the target is the database you’re moving data to. The replication instance processes the migration tasks and requires access to your source and target endpoints inside your VPC. Replication instances come in different sizes depending on your performance needs. If you’re migrating to a different database engine, AWS Schema Conversion Tool can generate the new schema for you.
AWS DMS Overview
During a migration, the service tracks are changed on the source database so that they can be applied to the target database for eventually keeping those two databases in sync.
AWS DMS supports both types of migrations:
a.) Homogeneous migrations (migrations between the same engine types).
b.) Heterogeneous migrations (migrations between different engine types).
AWS DMS: Change Data Capture
- A replication server is provisioned.
- Source and Target endpoints are defined.
- A task is created to perform the migration.
AWS DMS is a managed service that runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance.
This service completes its tasks in the following sequence:
- Establish Connection to the source database
- Reads the source data
- Formats the data for consumption by the target database.
- Loads the data into the target database.
Some Points to consider while using DMS:
- Provisioning a Replication Server:
- Smaller instance classes are sufficient for testing or small migrations.
- If during migration phase you plan to run many simultaneous tasks, then you should use large instances for consuming a fair amount of memory and CPU.
- Depending on the instance class of the replication server, you will get 50 GB OR 100 GB of data storage. It is used for log files and cached changes collected during the load. Usually, the default amount is sufficient.
- If your source database is busy or uses large transactions or if multiple tasks are performed on the replication server, you might need to increase the amount of storage.
- If you are using DMS for ongoing replication purpose, going for Multi-AZ instance will improve availability.
- Migration Type while creating a DMS Task
- Migrate existing data: If you can afford an outage to copy existing data, go for this option. It migrates data from source to target database, creating tables as needed.
- Migrate existing data and replicate ongoing changes:To capture changes in the source along with full data load, this option is available. It applies captured changes on target database after loading complete data. After application of changes reaches a steady state, you can shut down the applications and let remaining changes flow to the target, and restart the applications.
- Replicate data changes only:In situations where you want to replicate data after a specific time, this option is suitable. One of the scenarios where it is required would be in case of homogeneous migration, using native import mechanisms can be more efficient in loading bulk data. In this case, you need to specify a time from which DMS will begin to read changes from the database change logs.
It is mandatory to keep these logs active on the server for a limited period to ensure the access to changes from AWS DMS. This is ideally achieved by keeping the logs active for 24 hours or more than it during the migration process.
Hope it will help you in making decisions while using AWS Database Migration Service.