After your DTS instance migrates data to the destination database, this topic explains how to switch workloads with minimal business impact. The following steps use a migration instance as an example.
Prerequisites
A migration instance is configured and its status is Running or Completed. For more information about how to configure an instance, see Migration scenarios.
Overview
-
Stop application writes to the source database.
To prevent data loss, stop your application from writing new data to the source database.
-
Pause the migration instance.
After all data from the source database is written to the destination database, pause the migration instance.
-
Create and start a reverse migration instance.
Migrate incremental data from the destination database back to the source database in real time to provide a rollback solution. If an issue occurs after the switch, you can revert to the source database.
-
Switch workloads.
Point your application to the destination database and resume operations.
Usage notes
-
To minimize business impact, switch workloads during off-peak hours, as the process requires you to stop your application and database writes.
-
For easier session identification and improved data security, we recommend creating a dedicated database account for data migration.
-
To switch workloads, you must pause the migration instance. An instance that has been paused for more than seven days cannot be resumed.
-
To avoid extra charges for unused subscription tasks, especially those with auto-renewal enabled, disable auto-renewal or release the instance. For more information, see Renew a resource, , and release a DTS instance.
Procedure
Switch workloads
-
Wait for the migration instance to reach the Incremental Data Migration stage, and ensure that the latency in the Running Information column is less than 5 seconds.
NoteIf your migration instance does not have an Incremental Data Migration stage (that is, you did not select Incremental Data Migration for the Migration Types when configuring the instance), the task automatically completes after the initial data migration. Wait for the instance Status to change to Completed.
-
Temporarily stop your application to prevent new data from being written to the source database.
-
Log on to the source database and check the session information to confirm that no new write operations are active.
Common commands for viewing session information:
MySQL
show processlist;SQL Server
select * from sys.dm_exec_connections;Oracle
select sid,serial#,username,program,machine,status from v$session;PostgreSQL
select * from pg_stat_activity;Redis
CLIENT LISTMongoDB
use admin db.runCommand({currentOp: 1, $all:[{"active" : true}]})NoteThe results will include the connection from the DTS instance to the source database.
-
Pause the migration instance.
Important-
Do not resume a paused instance, as this can cause data inconsistency.
-
If your migration instance does not have an Incremental Data Migration stage, skip this step.
-
Wait for the migration instance latency to drop to 0 milliseconds.
Note-
If Auto Refresh is disabled, you can click the refresh icon
above the Actions column to update the latency. -
A latency of 0 may be transient.
This indicates that all pending data from the source database has been migrated to the destination database.
-
-
Wait for another 1 to 3 minutes.
During this time, the instance latency may fluctuate within a 2-second range.
-
In the Actions column for the instance, select .
In the Note dialog box, click OK.
-
Wait for the instance Status to change to Paused.
-
-
Create a reverse migration instance.
-
Keep your application stopped.
-
Remove the write restrictions on the source database.
-
Create and start a reverse migration instance.
Important-
When you configure the instance, select only Incremental Data Migration for the Migration Types.
-
For instructions on how to create an instance, see Migration scenarios.
-
-
Wait for the instance Status to change to Running.
-
-
Switch workloads.
-
Point your application to the destination database.
-
Resume application data writes.
-
Test your application functionality.
-
Rollback solution
Use this solution to restore service if the workload switch fails or other issues occur.
-
Stop your application from writing new data to the database.
-
Switch workloads back to the source database.
-
Resume application data writes.
Next steps
After switching to the destination database and verifying that your application is stable, test all related features. If you find no issues, you can terminate the reverse migration instance. For more information, see terminate a DTS instance.
The database account used for data migration has read and write permissions. For database security, delete this account or revoke its write permissions after the migration is complete.
FAQ
-
Q: What should I do with the original migration instance after switching workloads?
A: You can terminate or release the instance based on your needs. For more information, see terminate a DTS instance and release a DTS instance.
-
Q: What should I do if new data is accidentally written to the source database after the workload switch?
A: Use data validation to identify discrepancies between the source and destination databases, and then manually correct the data.
> Pause Task