Yes. For that purpose, you need to log in to the DTS Console with the Tencent Cloud account of the target TencentDB instance and select self-built database with public IP as the source instance type.
Yes. You can log in to the DTS Console and open the "Data Migration" page to do so.
No. When DTS performs data migration, it simply replicates the data of the source database with no impact on it.
Yes. When modifying the configuration for a created data migration task, you can select scheduled migration and specify the start time.
Source instances on version 3.2 or above cannot be migrated.
replicate_do_tablewill be set, and there will be one restart.
MySQL 5.1, 5.5, 5.6, and 5.7. As TencentDB no longer supports MySQL 5.1, you are recommended to upgrade MySQL 5.1 to MySQL 5.5 first and then migrate data to TencentDB for MySQL 5.5. You can also use DTS to directly migrate from a local MySQL 5.1 instance to a TencentDB for MySQL 5.5 instance.
In addition, the following restrictions apply:
You can click View Details to find a possible solution.
Possible reasons include:
You can click View Details on the right of the warning to view the cause and solution.
Currently, incremental migration is performed through the nearest proxy server via Tencent Cloud Direct Connect, which eliminates network jitters and ensures the quality of data transfer. The 15-day limit can reduce the connection pressure on the proxy server and is only intended for reasonable utilization of resources for migration. Currently, connections will not be force closed after 15 days.
As cold backup needs to be imported during migration,
binlog is disabled for higher write performance, resulting in loss of some data. To prevent data loss, you need to create a migration task first, confirm that the target instance is in sync, and then set the subscription feature for it.
In this case, TokuDB will be converted to InnoDB by default during migration. As tables containing clustered indices or compressed with TokuDB need to be pre-processed before migration, they are not supported currently. DDL operations on TokuDB are not supported either.
This is because session needs to be in binlog format for full check, which requires super permission. The solution is as follows:
TokuDB cannot be converted to InnoDB if there are tables compressed with TokuDB or containing clustered index in the source instance.