Cut over
The database cutover strategy is usually tightly coupled with the downtime requirements for the application. Strategies that you can use for the database cutover include offline migration, flash-cut migration, active/active database configuration, and incremental migration. These are discussed in the following sections.
Offline migration
If you can take your application offline for an extended period during write operations, you can use AWS DMS full-load task settings or one of the offline migration options for your data migration. The read traffic can continue while this migration is in progress, but the write traffic must be stopped. Because all the data needs to be copied from the source database, source database resources such as I/O and CPU are utilized.
At a high level, offline migration involves these steps:
-
Complete the schema conversion.
-
Start downtime for write traffic.
-
Migrate the data using one of the offline migration options.
-
Verify your data.
-
Point your application to the new database.
-
End the application downtime.
Flash-cut migration
In flash-cut migration, the main objective is to keep the downtime to a minimum. This strategy relies on continuous data replication (CDC) from the source database to the target database. All read/write traffic will continue on the current database while the data is being migrated. Because all the data needs to be copied from the source database, source server resources such as I/O and CPU are utilized. You should test to make sure that this data migration activity doesn’t impact your application performance SLAs.
At a high level, flash-cut migration involves these steps:
-
Complete the schema conversion.
-
Set up AWS DMS in continuous data replication mode.
-
When the source and target databases are in sync, verify the data.
-
Start the application downtime.
-
Roll out the new version of the application, which points to the new database.
-
End the application downtime.
Active/active database configuration
Active/active database configuration involves setting up a mechanism to keep the source and
target databases in sync while both databases are being used for write traffic. This strategy
involves more work than offline or flash-cut migration, but it also provides more flexibility
during migration. For example, in addition to experiencing minimal downtime during migration,
you can move your production traffic to the new database in small, controlled batches instead of
performing a one-time cutover. You can either perform dual write operations so that changes are
made to both databases, or use a bi-directional replication tool like HVR
At a high level, active/active database configuration involves these steps:
-
Complete the schema conversion.
-
Copy the existing data from the source database to the target database, and then keep the two databases in sync by using a bi-directional replication tool or dual writes from the application.
-
When the source and target databases are in sync, verify the data.
-
Start moving a subset of your traffic to the new database.
-
Keep moving the traffic until all your database traffic has been moved to the new database.
Incremental migration
In incremental migration, you migrate your application in smaller parts instead of performing a one-time, full cutover. This cutover strategy could have many variations, based on your current application architecture or the refactoring you’re willing to do in the application.
You can use a design pattern