This topic describes how to switch your workloads to the target database and prepare a rollback solution. This allows you to minimize the negative impact of data migration on your business.

Prerequisites

A data migration task is configured and it is in the Migrating or Completed state.

Notes

  • We recommend that you switch workloads to the target database during off-peak hours to minimize the disruption to your normal operations. Before you switch workloads to the target database, you must suspend all write requests to the source database and schedule a downtime for your application.
  • We recommend that you create separate accounts for data migration and assign it the required permissions. This will help you identify sessions used by DTS and manage your security more easily.

Procedure

  1. Wait until the task progress bar shows Incremental Data Migration and The migration task is not delayed or a delay time of less than 5 seconds.
    Note If you do not select Incremental Data Migration when creating the data migration task, the task progress bar does not show Incremental Data Migration. After data is migrated, the migration task automatically ends. In this case, you must suspend all write requests to the source database before starting the data migration task. Skip to step 5 and proceed.
  2. To suspend write requests to the source database, stop your application and make the source database read-only.
  3. Log on to the source database and make sure that no new sessions are created that write into the source database. Depending on your database engine, run one of the following statements to view session information:
    show processlist;
    select * from sys.dm_exec_connections;
    select sid,serial#,username,program,machine,status from v$session;
    select * from pg_stat_activity;
    CLIENT LIST
    use admin
    db.runCommand({currentOp: 1, $all:[{"active" : true}]})

    Note By running the preceding statements, you can view the processes or sessions between DTS and the source database.
  4. After the status of incremental data migration changes to The migration task is not delayed (the source and target are fully in sync), wait for one minute or longer, and then manually stop the migration task.
    The migration task is not delayed
  5. While the application is stopped, make the source database writable again.
  6. Create and start a migration task in the reverse direction so that new updates made to the target database are replicated to the source database. The migration in the reverse direction makes sure that the two databases are synchronized so that you can switch workloads back to the source database if an error occurs. When you create this migration task, select only the Incremental Data Migration phase.

    For example, if migrate from a user-created MySQL database to an ApsaraDB RDS for MySQL instance, you can refer to the procedure described in Migrate data from an ApsaraDB RDS for MySQL database to a user-created MySQL database (select only Incremental Data Migration) to create a migration task in the reverse direction.

    Warning When you configure a data migration task in the reverse direction, you must select only Incremental Data Migration in the Configure Migration Types and Objects step. Then, you must select the database or table to be replicated back to the source database.Select only Incremental Data Migration
  7. Verify that the source and target databases are in sync, modify your application to connect to the target database, and then restart your application.
Note With the data migration task in the reverse direction, updates made to the target database are replicated back to the source database and these two databases are in sync. If the target database fails during the test period, you can switch workloads back to the source database.

Next steps

After you switch workloads to the target database and test all application features, you can stop the task in the reverse direction (target-to-source). For more information, see Stop a data migration task.

Warning The database accounts used for data migration have the read/write permissions. After the migration is complete, you must remove permissions from these accounts or delete the accounts to avoid security risks.

FAQ

  • Q: What can I do if an error occurs after I switch workloads to the target database?

    A: If an error occurs, you can switch workloads back to the source database. After you create a data migration task in the reverse direction, updates made to the target database are replicated back to the source database in real time.

  • Q: How can I ensure data consistency in the source database if I am unable to switch workloads to the target database?

    A: You can back up the source database before switching workloads.

  • Q: What can I do if updates are unexpectedly written to the source database after I switch workloads to the target database?

    A: You can manually compare the data objects in source and target databases and apply corrections.