Migrate all existing data from a self-managed TiDB database to an ApsaraDB RDS for MySQL instance by using DTS.
Prerequisites
Create a destination ApsaraDB RDS for MySQL instance with more storage than the source TiDB database. Create an ApsaraDB RDS for MySQL instance.
-
This feature is available only in specific regions. The destination ApsaraDB RDS for MySQL instance must be in one of the following regions: China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Shenzhen), China (Zhangjiakou), China (Hong Kong), Singapore, US (Silicon Valley), or US (Virginia).
-
The storage of the destination instance must exceed that of the source TiDB database.
Usage notes
-
A full data migration consumes read and write resources on both the source and destination databases, increasing their server load. This added load can degrade performance or cause service unavailability, especially if your databases have poor performance, low specifications, or are already busy (for example, with many slow SQL queries, tables without primary keys, or deadlocks in the destination database). Before you start the migration, evaluate the performance of both databases and perform the migration during off-peak hours, for example, when CPU utilization is below 30%.
-
If a source table to be migrated lacks a primary key or unique constraint, duplicate data may occur in the destination database.
-
For FLOAT and DOUBLE columns, DTS reads values using
ROUND(COLUMN,PRECISION). If a column's precision is not explicitly defined, DTS defaults to a precision of 38 for FLOAT and 308 for DOUBLE. Verify that this precision meets your business requirements. -
DTS automatically creates a database in the destination ApsaraDB RDS for MySQL instance. However, if the source database name does not comply with ApsaraDB RDS naming conventions, you must create a new database with a valid name in the destination instance before configuring the migration task.
NoteFor more information about the naming conventions and how to create a database, see Create a database.
-
DTS automatically attempts to recover failed migration tasks. To prevent an automatic recovery from overwriting data on the destination instance after you switch over, stop or release the migration task before switching your business.
Billing
|
Type |
Link specification fee |
Public traffic fee |
|
Schema migration and full data migration |
Free. |
Data egress from Alibaba Cloud over the public network incurs charges. Billing overview. |
Migration types
|
Type |
Description |
|
Schema migration |
DTS migrates the schema definitions of selected objects to the destination database. DTS currently supports schema migration for databases, tables, and views. Warning
TiDB-to-MySQL migration involves heterogeneous databases. Data types may not be fully compatible. Evaluate the impact of data type mapping on your business. Data type mapping for heterogeneous databases. |
|
Full data migration |
DTS migrates all existing data from the selected objects to the destination database. Note
The destination tablespace may be larger than the source after migration due to table fragmentation from concurrent |
Preparations
If the source TiDB database uses a security whitelist, add the CIDR blocks of DTS servers to it. Add the IP address CIDR blocks of DTS servers to a whitelist.
Procedure
-
Log on to the DTS console.
NoteIf you are automatically redirected to the Data Management (DMS) console, you can click the
icon in the lower-right corner and then click
to return to the classic DTS console. -
In the left-side navigation pane, click Data Migration.
-
At the top of the Migration Tasks page, select the region of the destination cluster.
-
In the upper-right corner of the page, click Create Data Migration Task.
-
Configure the source and destination databases.

Category
Parameter
Description
N/A
Task name
DTS automatically generates a task name. Use a descriptive name for easy identification. The name does not need to be unique.
Source Database
Instance type
Select the deployment location of the source database. This topic uses Self-managed database on an ECS instance as an example.
NoteIf your self-managed database is a different instance type, you must perform additional preparations. For more information, see Preparations.
Instance region
Select the region of the ECS instance that hosts the TiDB database.
Database type
Select TiDB.
Port
Enter the service port of the TiDB database. Default: 4000.
Database account
Enter the account for the TiDB database. The account must have SHOW VIEW and SELECT permissions on the objects to be migrated.
Database password
Enter the password for the database account.
ImportantAfter you enter the source database information, you can click Test Connectivity next to Database Password to verify that the information is correct. If the information is correct, the message Passed is displayed. If the message Failed is displayed, click Diagnose next to the Failed message and adjust the source database information based on the prompts.
Destination Database
Instance type
Select RDS Instance.
Instance region
Select the region of the destination RDS instance.
RDS instance ID
Select the ID of the destination RDS instance.
Database account
Enter the account for the destination RDS instance. The account must have read and write permissions on the destination database. Create an account and Modify account permissions.
Database password
Enter the password for the database account.
ImportantAfter you enter the destination database information, you can click Test Connectivity after Database Password to verify that the entered information is correct. If the information is correct, a Passed message is displayed. If a Failed message is displayed, click Diagnose after Failed and adjust the destination database information based on the prompts.
Connection method
Select Non-encrypted or SSL-encrypted as required. If you select SSL-encrypted, you must enable SSL encryption for the RDS instance beforehand. Set SSL encryption.
ImportantThe Encryption parameter is supported only in Chinese mainland regions and the China (Hong Kong) region.
-
Click Set Whitelist and Next.
If the source or destination is an Alibaba Cloud database instance (such as an ApsaraDB RDS for MySQL or ApsaraDB for MongoDB instance), DTS automatically adds the CIDR blocks of the DTS servers in the corresponding region to the whitelist of the database instance. If the source or destination is a self-managed database on an ECS instance, DTS automatically adds the CIDR blocks of the DTS servers in the corresponding region to the security rules of the ECS instance. You must also ensure that the self-managed database allows access from the ECS instance. If the database is a cluster deployed on multiple ECS instances, you must manually add the CIDR blocks of the DTS servers to the security rules of each ECS instance. If the source or destination is a self-managed database in an on-premises data center or another cloud, you must manually add the CIDR blocks of the DTS servers to allow access from them. For the CIDR blocks of DTS servers, see CIDR blocks of DTS servers.
WarningAdding public IP addresses of DTS servers, whether automatically or manually, may introduce security risks. By using this product, you acknowledge and accept these potential risks. You are responsible for implementing basic security measures, such as using strong passwords, restricting open ports, using authentication for internal APIs, regularly reviewing and limiting unnecessary network segments, or connecting by using private connections such as Express Connect, VPN Gateway, or Smart Access Gateway.
-
Select the migration types and migration objects.

Parameter
Description
Migration type
Select both Schema Migration and Full Data Migration. Migration types.
ImportantTo ensure data consistency, avoid DDL operations on the source database during the full data migration.
Migration objects
From the Available list, select the objects to migrate and click
to move them to the Selected Objects list.Important-
You can select databases, tables, or columns as the objects to migrate.
-
By default, migrated object names remain unchanged. To rename objects in the destination database, use the object name mapping feature. Map objects.
-
If you use object name mapping, other objects that depend on the renamed object may fail to migrate.
Change mapped name
Rename objects in the destination instance by using the object name mapping feature. Map objects.
Retry duration for unstable connections
Default: 12 hours. You can specify a custom duration. If DTS reconnects to both databases within this period, the task resumes automatically. Otherwise, it fails.
NoteThe DTS instance incurs charges during retry. Specify a reasonable retry duration based on your needs, or release the DTS instance after the source and destination databases are released.
-
After you complete the configuration, click Precheck and Start in the lower-right corner of the page.
Note-
Before the migration task starts, DTS runs a precheck. The task can start only after it passes the precheck.
-
If the precheck fails, click the
icon next to the failed item to view details.-
Fix the issues as prompted and run the precheck again.
-
If you do not need to fix the warning items, you can select Ignore and then click Ignore Warnings and Rerun Precheck to run the precheck again.
-
-
-
After the task passes the precheck, click Next.
-
In the Confirm Settings dialog box that appears, select a Instance Class and select the Data Transmission Service (pay-as-you-go) Service Terms checkbox.
-
Click Purchase and Start. The migration task starts.
WarningDo not manually stop the task, or the migrated data may be incomplete. Wait for the task to finish; DTS stops it automatically upon completion.

Next steps
After the full data migration is complete, you can perform an incremental data migration. Migrate incremental data from a self-managed TiDB database to an ApsaraDB RDS for MySQL instance.