Why does system prompt unable to access the database in DTS migration process?

Possible reasons for failure to access the database include: The source library or target library is unavailable, or the privilege is insufficient, or the number of connections is full. The user needs to check the source library and the target library according to the reasons, and then continue to start the task after troubleshooting.

Why is the migration progress recalculated after restarting from the pause of full migration task?

After the full migration task is restarted, to ensure the consistency of data, the original data will be deleted and then the full migration will be restarted. So, during the full migration process, do not write data into the target database, otherwise, the data will be deleted after restart.

Why can’t data be written into the source library in the full migration process?

During the full migration, if the migrated tables do not have a primary key or unique key, to ensure the data consistency, these tables will be read-only locked. During read-only locking, data cannot be written into these tables, but other tables with a primary key or unique key will not be affected.

Why does duplicate data appear in the target database after restarting from the pause of incremental migration?

After the incremental migration task is restarted, the migration will be continued from the previously saved location. If the migrated table does not have a primary key or unique key, duplicate data will appear. To avoid this problem, it is required to guarantee that the migrated table has a primary key or unique key.

Can normal migration or synchronization be continued after master-slave switch of the source library?

If the new source library has the same binlog position or gitd after the source library is switched, and the access ip of the given source library is unchanged, normal migration and synchronization can be performed, otherwise cannot be continued.

Can normal migration and synchronization be continued after master-slave switch of the target library?

If the access ip of the given target library is unchanged after the target library is switched, normal migration and synchronization can be continued, otherwise, cannot be continued.

The console shows that the task is running, but the target library has no data?

The possible reasons are as follows:

• In case of network delay or heavy DTS load, there will be data delay, you can wait for a while and recheck.
• If the delay is abnormal, there may be a DTS internal exception, which needs to be self-repaired. This may cause slow data migration for a short time.

Why is an error reported when modifying the library name or the table name of the target database, in data migration process?

Users need to ensure that there is a corresponding table under the new database when modifying the database name or table name of the target database, otherwise an error will be reported.