Use Data Transmission Service (DTS) to migrate data from an ApsaraDB RDS for MariaDB TX instance to an ApsaraDB RDS for MySQL instance. DTS supports schema migration, full data migration, and incremental data migration. Combining all three types minimizes downtime and keeps data consistent throughout the migration.
Prerequisites
Before you begin, make sure that you have:
An ApsaraDB RDS for MySQL instance. See Create an ApsaraDB RDS for MySQL instance
Enough storage on the MySQL instance — the available storage must exceed the total data size of the MariaDB TX instance
Database accounts with the required permissions on both instances. See Permissions required for database accounts
How it works
DTS migrates your data in up to three phases:
Schema migration: Copies the schemas of tables, views, triggers, stored procedures, and functions to the destination. Events are not migrated. For views, stored procedures, and functions, DTS changes the SECURITY attribute from DEFINER to INVOKER — grant read and write permissions to INVOKER to call them on the destination.
Full data migration: Copies all existing data to the destination. Concurrent INSERT operations cause table fragmentation in the destination, so the destination tablespace will be larger than the source after this phase completes. To ensure successful data migration, do not perform DDL operations on the source database during full data migration.
Incremental data migration: After full data migration finishes, DTS reads binary log files from the source and replicates ongoing changes to the destination in real time.
To ensure service continuity, select all three migration types when you create the task.
Billing
| Migration type | Task configuration fee | Internet traffic fee |
|---|---|---|
| Schema migration and full data migration | Free | Charged only when migrating from Alibaba Cloud over the Internet. See Billing overview. |
| Incremental data migration | Charged. See Billing overview. | — |
SQL operations supported during incremental data migration
| Operation type | SQL statements |
|---|---|
| DML | INSERT, UPDATE, DELETE, REPLACE |
| DDL | ALTER TABLE, ALTER VIEW, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, DROP INDEX, DROP TABLE, RENAME TABLE, TRUNCATE TABLE |
Permissions required for database accounts
| Database | Schema migration | Full data migration | Incremental data migration |
|---|---|---|---|
| ApsaraDB RDS for MariaDB TX instance | SELECT | SELECT | REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, SELECT |
| ApsaraDB RDS for MySQL instance | Read and write | Read and write | Read and write |
To create accounts and grant permissions:
MariaDB TX instance: See Create an account on an ApsaraDB RDS for MariaDB TX instance.
MySQL instance: See Create an account on an ApsaraDB RDS for MySQL instance and Modify the permissions of a standard account for an ApsaraDB RDS for MySQL instance.
Usage notes
Performance impact
DTS uses read and write resources on both the source and destination during migration. High load can degrade database performance — especially when the source has many slow SQL queries, tables without primary keys, or when deadlocks occur on the destination. Run migration tasks during off-peak hours, when CPU utilization on both instances is below 30%.
Data consistency
Source tables must have PRIMARY KEY or UNIQUE constraints with all fields unique. Without these constraints, the destination may contain duplicate records.
If you select only full data migration (no incremental), avoid writing to the source database during migration to keep both sides consistent.
Task resumption
If a migration task fails, DTS automatically resumes it. Before you switch workloads to the destination instance, stop or release the migration task — otherwise, data from the source will overwrite the destination after the task resumes.
Create a migration task
Step 1: Open the data migration page
Use either the DTS console or the Data Management Service (DMS) console to start.
DTS console
Log on to the DTS console.
In the left-side navigation pane, click Data Migration.
In the upper-left corner, select the region where the migration instance resides.
DMS console
The actual steps may vary based on the DMS console mode and layout. See Simple mode and Customize the layout and style of the DMS console.
Log on to the DMS console.
In the top navigation bar, choose Data + AI > DTS (DTS) > Data Migration.
From the drop-down list to the right of Data Migration Tasks, select the region where the migration instance resides.
Step 2: Configure source and destination databases
Click Create Task.
Read the Limits displayed at the top of the configuration page before proceeding — ignoring them may cause task failure or data inconsistency.
Configure the source and destination databases using the following parameters.
Source database
| Parameter | Description |
|---|---|
| Task Name | A name for the DTS task. DTS generates a default name. Specify a descriptive name to help identify the task later. Task names do not need to be unique. |
| Select Existing Connection | If you have a database instance registered with DTS, select it from the drop-down list — DTS fills in the connection details automatically. See Manage database connections. In the DMS console, you can select the database instance from the Select a DMS database instance drop-down list. Otherwise, configure the parameters below. |
| Database Type | Select MariaDB. |
| Access Method | Select Alibaba Cloud Instance. |
| Instance Region | Select the region of the source ApsaraDB RDS for MariaDB TX instance. |
| Replicate Data Across Alibaba Cloud Accounts | Select No (both instances belong to the same Alibaba Cloud account in this example). |
| Instance ID | Select the ID of the source ApsaraDB RDS for MariaDB TX instance. |
| Database Account | Enter the database account for the source instance. See Permissions required for database accounts. |
| Database Password | Enter the password for the database account. |
| Encryption | Select Non-encrypted. |
Destination database
| Parameter | Description |
|---|---|
| Select Existing Connection | If you have a database instance registered with DTS, select it from the drop-down list. See Manage database connections. In the DMS console, you can select the database instance from the Select a DMS database instance drop-down list. Otherwise, configure the parameters below. |
| Database Type | Select MySQL. |
| Access Method | Select Alibaba Cloud Instance. |
| Instance Region | Select the region of the destination ApsaraDB RDS for MySQL instance. |
| Replicate Data Across Alibaba Cloud Accounts | Select No. |
| RDS Instance ID | Select the ID of the destination ApsaraDB RDS for MySQL instance. |
| Database Account | Enter the database account for the destination instance. See Permissions required for database accounts. |
| Database Password | Enter the password for the database account. |
| Encryption | Select Non-encrypted or SSL-encrypted based on your requirements. To use SSL encryption, enable it on the MySQL instance first. See Use a cloud certificate to enable SSL encryption. |
Click Test Connectivity and Proceed.
DTS server CIDR blocks must be added to the security settings of the source and destination databases. See Add the CIDR blocks of DTS servers. If the source or destination database is a self-managed database and its access method is not set to Alibaba Cloud Instance, click Test Connectivity in the CIDR Blocks of DTS Servers dialog box.
Step 3: Select migration objects
On the Configure Objects page, configure the following parameters.
| Parameter | Description |
|---|---|
| Migration Types | Select Schema Migration, Full Data Migration, and Incremental Data Migration to ensure service continuity. If you select only Schema Migration and Full Data Migration, avoid writing to the source during migration. If you skip Schema Migration, create the target database and table before running the task and enable object name mapping in Selected Objects. |
| Method to Migrate Triggers in Source Database | Select a method to migrate triggers. If no triggers are involved, skip this parameter. For details, see Configure the method to synchronize or migrate triggers. This parameter is available only when both Schema Migration and Incremental Data Migration are selected. |
| Processing Mode of Conflicting Tables | Precheck and Report Errors (default): The precheck fails if the destination has tables with the same names as the source. Use object name mapping to rename conflicting tables. See Map object names. Ignore Errors and Proceed: Skips the precheck for duplicate table names. During full data migration, existing records in the destination are retained if a primary key conflict occurs. During incremental data migration, existing records are overwritten. If the schemas differ between source and destination, only specific columns are migrated or the task may fail. |
| Source Objects | Select objects to migrate and click the right-arrow icon to add them to Selected Objects. You can select columns, tables, or databases. Selecting tables or columns excludes other objects such as views, triggers, and stored procedures. |
| Selected Objects | To rename a single object, right-click it. To rename multiple objects at once, click Batch Edit. See Map object names. Renaming objects may cause dependent objects to fail during migration. To filter rows, right-click a table and configure a SQL filter condition. See Configure SQL conditions to filter data. To select specific DML or DDL operations for incremental migration at the database or table level, right-click the object and choose the operations. |
Click Next: Advanced Settings.
Step 4: Configure advanced settings
| Parameter | Description |
|---|---|
| Dedicated Cluster for Task Scheduling | By default, DTS schedules the task to a shared cluster. Purchase a dedicated cluster for better stability. See What is a DTS dedicated cluster. |
| Retry Time for Failed Connections | How long DTS retries after losing connection to the source or destination. Valid range: 10–1,440 minutes. Default: 720 minutes. Set this to at least 30 minutes. If the connection is restored within this window, DTS resumes the task. If multiple tasks share the same database, the most recently set value applies. DTS charges during retry periods. |
| Retry Time for Other Issues | How long DTS retries after DDL or DML operation failures. Valid range: 1–1,440 minutes. Default: 10 minutes. Set this to greater than 10 minutes. This value must be less than Retry Time for Failed Connections. |
| Enable Throttling for Full Data Migration | Limits the read/write load on the source and destination during full data migration. When enabled, configure Queries per second (QPS) to the source database, RPS of Full Data Migration, and Data migration speed for full migration (MB/s). Available only when Full Data Migration is selected. |
| Enable Throttling for Incremental Data Migration | Limits load during incremental data migration. When enabled, configure RPS of Incremental Data Migration and Data migration speed for incremental migration (MB/s). Available only when Incremental Data Migration is selected. |
| Environment Tag | An optional tag to identify the DTS instance. You can select an environment tag based on your business requirements. |
| Configure ETL | Enables the extract, transform, and load (ETL) feature. Select Yes to enter data processing statements in the code editor. See Configure ETL in a data migration or data synchronization task. Select No to skip ETL. |
| Monitoring and Alerting | Sends alerts if the task fails or migration latency exceeds a threshold. Select Yes and configure the alert threshold and notification settings. See Configure monitoring and alerting when you create a DTS task. |
Step 5: Run the precheck
Click Next: Save Task Settings and Precheck.
To preview the OpenAPI parameters for this task configuration, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.
DTS runs a precheck before starting the migration task. If any item fails:
Click View Details next to the failed item, fix the issue, then click Precheck Again.
If an alert item can be ignored, click Confirm Alert Details, then click Ignore in the dialog box. Click OK to confirm, then click Precheck Again. Ignoring alerts may cause data inconsistency.
Step 6: Purchase an instance and start the task
Wait for Success Rate to reach 100%, then click Next: Purchase Instance.
On the Purchase Instance page, configure the instance class.
Parameter Description Resource Group The resource group for the migration instance. Default: default resource group. See What is Resource Management? Instance Class The instance class determines migration speed. See Instance classes of data migration instances. Read and select the check box for Data Transmission Service (Pay-as-you-go) Service Terms.
Click Buy and Start, then click OK in the confirmation dialog.
View task progress on the Data Migration page.
If only schema migration and full data migration are running, the task stops automatically when complete. The status shows Completed.
If incremental data migration is running, the task continues indefinitely. The status shows Running.
What's next
The database accounts used for migration have read and write permissions. After migration is complete, delete those accounts on both the ApsaraDB RDS for MariaDB TX instance and the ApsaraDB RDS for MySQL instance to reduce security exposure.