Data Transmission Service:Switch workloads to the destination database

Usage notes

• We recommend that you switch workloads to the destination database during off-peak hours to minimize the negative impact. Before you switch workloads to the destination database, you must stop writing data to the source database and suspend the business.
• We recommend that you create and authorize a database account for data migration. This allows you to distinguish session information and improve data security.

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 The task progress bar shows Incremental Data Migration only if Incremental Data Migration is selected when you configure the data migration task. After data is migrated, the migration task automatically stops. In this case, you must suspend the business and stop writing data to the source database before you run the data migration task. Go to Step 5 and proceed.
2. Suspend the business and stop writing data to the source database.
3. Log on to the source database and run the following statements based on the database type to view session information. Make sure that no new sessions are used for write operations.
   MySQL SQL Server Oracle PostgreSQL Redis MongoDB

   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 You can run the preceding statements to 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 again, wait for 1 minute or longer, and then manually stop the migration task.
   Warning After the data migration task is stopped, do not start the task unless necessary. Otherwise, the migrated data may be inconsistent with the original data.

   
5. When the business is still suspended, remove the limit on writing data to the source database.
6. Create and start a task to migrate incremental data generated in the destination database to the source database. The migration task created in this step provides a rollback solution. If an error occurs in the destination database, you can switch workloads to the source database.

   For example, if the original migration task is used to migrate data from a self-managed MySQL database to an ApsaraDB RDS for MySQL instance, you need to create a migration task to migrate data from the ApsaraDB RDS for MySQL instance to the self-managed MySQL database in this step. For more information, see Migrate data from an ApsaraDB RDS for MySQL instance to a self-managed MySQL database. When you create the migration task in the opposite direction, select only Incremental Data Migration.

   Warning When you configure a data migration task in the opposite 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 migrated back to the source database.

   
7. Switch workloads to the destination database and manually terminate or release the data migration task.
8. After you run the task in the opposite direction, incremental data generated in the destination database is migrated back to the source database in real time. If the business fails, you can switch workloads back to the source database.

What to do next

After you switch workloads to the destination database and test all the business-related features, you can stop the task in the opposite direction. For more information, see Stop a data migration task.

FAQ

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

  A: If an error occurs, you can switch workloads back to the source database. After you run the task in the opposite direction, incremental data generated in the destination database is migrated back to the source database in real time.

• Q: How do I ensure that data in the source database is consistent with that before the switchover if workloads fail to be migrated to the destination database?

  A: You can back up the source database before you switch workloads. If the workloads fail to be switched to the destination database, you can restore the source database to ensure data consistency.

• Q: What do I do if data is written to the source database due to a misoperation after I switch workloads to the destination database?

  A: You can use the data verification feature to compare the data of the source and destination databases. Then, you can make changes to ensure data consistency.