DTS supports data migration between homogeneous and heterogeneous data sources, covering scenarios such as migrating to the cloud, migrating between Alibaba Cloud instances, and database sharding and scaling. This page lists supported source databases, destination databases, and migration types for each scenario, with links to configuration guides.
Migration types
| Migration type | Description | Use when |
|---|---|---|
| Schema migration | DTS migrates schema definitions—tables, views, triggers, stored procedures, and indexes—from the source to the destination. For heterogeneous databases, DTS converts syntax automatically. For example, NUMBER in Oracle becomes DECIMAL in MySQL. | Use as the first step for relational databases. |
| Full data migration | DTS migrates all existing data from the source to the destination. New data written after the task starts is not migrated. | Use alone only when the source database has no writes during migration. |
| Incremental data migration | DTS reads incremental change statements from the source in real time—for example, from MySQL binary logs—converts them for the destination database type, and replays them. Tasks run continuously and do not stop automatically. Stop or release them manually when the migration is complete. | Use together with full data migration when the source has active writes, or when zero-downtime migration is required. |
To migrate with no downtime, select Schema Migration, Full Data Migration, and Incremental Data Migration when configuring the migration task. Do not write new data to the source database if you select only schema migration and full data migration—new data written after the task starts will not be migrated.
Data migration vs. data synchronization
Data migration can serve as a substitute for data synchronization in some scenarios, but data synchronization provides greater network stability and additional features. Use data synchronization when your workload requires those capabilities. For details, see What are the differences between data migration and data synchronization?.
Usage notes
Cross-region and cross-border tasks
A cross-region or cross-border task has its source and destination databases in different regions—for example, a source RDS instance in the Singapore region and a destination RDS instance in the China (Hangzhou) region.
If the Access Method for the source database is set to Alibaba Cloud Instance, the source database must have a public endpoint.
If the Access Method for the source database is not set to Alibaba Cloud Instance, the destination database must have a public endpoint.
Cross-border and cross-region task bandwidth is limited to 100 Mbit/s. To use higher bandwidth, configure the cross-region network bandwidth through CEN before creating the DTS task.
Cross-account migration
Whether you can create a cross-Alibaba Cloud account migration task depends on the database type and connection type. Set the Replicate Data Across Alibaba Cloud Accounts configuration item to Yes for the source or destination database instance. For configuration steps, see Configure a cross-Alibaba Cloud account task.
Source database requirements
| Requirement | Details |
|---|---|
| Network bandwidth | 100 Mb/s or higher. For incremental migration tasks, the round-trip time (RTT) between the source database and DTS, and between DTS and the destination database, must be less than 2 ms. Higher RTT causes task latency. For example, a database in the Singapore region connecting to DTS through a VPN gateway in the Hong Kong (China) region will experience significant latency. |
| Log volume | Peak log volume must be less than 1 TB. Average hourly log volume must be less than 50 GB. Peak traffic must be less than 15 MB/s. DTS pulls logs for the entire database instance by default—high change volume in objects not being migrated can also cause task latency. |
| Batch operations | Batch data updates or large-scale changes to LOB (Large Object) data types such as CLOB, BLOB, and LONG can cause latency. Run these in smaller batches or avoid them during migration. |
| Tables without primary keys | Avoid frequent DELETE or UPDATE operations on tables without primary keys—this can cause task latency. |
| DDL operations | Keep DDL operations to fewer than 10 statements per second to avoid task latency. |
| Large transactions | Avoid single transactions that generate more than 100 GB of logs—these can cause the task to fail. |
FAQ
Does DTS support Serverless ApsaraDB RDS for MySQL instances?
Yes.
Does DTS support PolarDB for MySQL serverless clusters?
Yes.
Does DTS support RDS for PostgreSQL serverless instances?
RDS for PostgreSQL serverless instances are supported as a destination database, but not as a source database.
Does DTS support instances in ApsaraDB for MyBase dedicated clusters?
Yes. DTS can read data from database instances created in ApsaraDB for MyBase using the Alibaba Cloud Instance Access Method. Refer to the configuration document for your specific database link in the migration solutions tables below. For example, Migrate data from a self-managed MySQL database to an ApsaraDB RDS for MySQL instance applies to migrating to a MySQL instance in an ApsaraDB for MyBase dedicated cluster.
What is a self-managed database?
A self-managed database is a database where the Access Method is not set to Alibaba Cloud Instance when configuring a DTS task. This includes databases on third-party cloud platforms, on-premises databases, and databases deployed on ECS instances.
Why does the estimated total differ from the completed count during full migration?
The estimated total is based on database performance statistics, which can be inaccurate. For authoritative data counts, rely on the results from the full data validation phase.