How can I perform a database migration cut over when using AWS DMS?
Last updated: 2019-10-03
How can I perform a database migration cut over for AWS Database Migration Service (AWS DMS)?
Before performing a production database cut over, it's a best practice to test all the migration steps. During the test, document all the migration steps, and be sure to document issues that you encounter and how to fix them. By testing the migration, you reduce the likelihood that you'll encounter issues during a production migration.
Then, during a production database migration, use the same AWS DMS replication engine version, configuration, and scripts that you used in the successful testing phase.
Before you begin a migration, notify stakeholders that are dependent on the database about the migration and the estimated migration time. You can estimate the migration time based on the statistics from your test migration.
Then, stop all applications and users from accessing the source database (block all database users except for admin users and AWS DMS users). Confirm that scheduled database tasks and jobs are suspended to ensure that the source and target databases are synced. The cut over phase begins after you stop all access to the database.
The following checklist is generic, so be sure to customize the cut over plan to meet the needs of your use case, and tune your plan based on the results of your migration test.
Cut over checklist
- Monitor AWS DMS CDC tasks logs, table statistics, and entries in the Apply Exceptions table (dmslogs.awsdms_apply_exceptions) to confirm that there are no errors when the changes are applied to the target database.
- After all source database activities are suspended, monitor the Amazon CloudWatch metric for CDCLatencyTarget. When the metric reaches zero seconds, the target database is in sync with the source database.
- Use AWS DMS data validation to confirm that the table data was migrated correctly from the source to the target.
- Stop all AWS DMS tasks.
- Create other schema objects (secondary indexes, database triggers, stored procedures, foreign keys, etc.) that aren't migrated by AWS DMS, if they weren't created on the target database before starting the full load. Be sure that database triggers are enabled and that indexes and other schema objects are in a valid state.
- Configure application settings to use the new database.
- It's a best practice to have an application quality assurance team test the new database to verify that all applications work as expected on the new database.
- Unlock database users to give them access to the new migrated database.
- Resume any database jobs that you suspended.
If there are failures and you can't recover during the allowed downtime, have a rollback plan in place that allows you to switch back to the original database.