All Products
Search
Document Center

Data Transmission Service:Migrate data from RDS for MariaDB to RDS for MySQL

Last Updated:Jun 16, 2026

Data Transmission Service (DTS) can migrate data from an ApsaraDB RDS for MariaDB instance to an ApsaraDB RDS for MySQL instance. By using schema migration, full data migration, and incremental data migration together, you can migrate your database with minimal application downtime.

Prerequisites

An ApsaraDB RDS for MySQL instance is created. For more information, see Create an ApsaraDB RDS for MySQL instance.

Note

Ensure that the storage space of the destination ApsaraDB RDS for MySQL instance is larger than the space used by the source database.

Precautions

  • During a full data migration, DTS consumes read and write resources on the source and destination databases, increasing their load. If your databases have poor performance, low specifications, or high workloads (for example, if the source database has many slow SQL queries or tables without primary keys, or if deadlocks occur in the destination database), the increased load can strain your databases or even cause service interruptions. Perform the data migration during off-peak hours, such as when the CPU utilization of both databases is below 30%.

  • If a source table lacks a primary key or a unique constraint and contains non-unique data, duplicate data may be created in the destination database.

  • If a data migration task fails, DTS automatically resumes it. Before you switch services to the destination instance, stop or release the migration task to prevent it from overwriting data in the destination instance with data from the source database.

Billing

Migration type

Task configuration fee

Internet traffic fee

Schema migration and full data migration

Free of charge.

DTS charges an Internet traffic fee when the Access Method of the destination database is set to Public IP Address. Billing overview.

Incremental data migration

Charged. Billing overview.

Migration types

  • Schema migration

    DTS migrates the schemas of the selected objects to the destination database. Schema migration is supported for tables, views, triggers, stored procedures, and functions, but not for events.

    Note
    • During schema migration, DTS changes the DEFINER of views, stored procedures, and functions to INVOKER.

    • Because DTS does not migrate user information, grant the invoker the required read and write permissions to call these objects in the destination database.

  • Full data migration

    DTS migrates all existing data from the selected objects to the destination database.

    Note
    • During full data migration, concurrent INSERT operations can cause table fragmentation in the destination database. As a result, the table space in the destination database may be larger than that in the source database after migration.

    • To ensure a successful migration, do not perform DDL operations on the source database during full data migration.

  • Incremental data migration

    After full data migration, DTS reads the binlog of the source database and migrates subsequent data changes to the destination database in real time.

SQL operations for incremental migration

Operation type

SQL statement

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

Database account permissions

Database

Schema migration

Full data migration

Incremental data migration

ApsaraDB RDS for MariaDB instance

SELECT

SELECT

REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, and SELECT

ApsaraDB RDS for MySQL instance

Read and write permissions

Read and write permissions

Read and write permissions

To create a database account and grant permissions:

Procedure

  1. Log on to the DTS console.

    Note

    If you are automatically redirected to the Data Management (DMS) console, you can click the jiqiren icon in the lower-right corner and then click 返回旧版 to return to the classic DTS console.

  2. In the left-side navigation pane, click Data Migration.

  3. At the top of the Migration Tasks page, select the region of the destination cluster.

  4. In the upper-right corner of the page, click Create Data Migration Task.

  5. Configure the connection settings for the source and destination databases.

    Section

    Parameter

    Description

    N/A

    Task name

    DTS automatically generates a task name. Use a descriptive name to easily identify the task. The name does not need to be unique.

    Source Database

    Instance type

    Select RDS Instance.

    Instance region

    Select the region where the source ApsaraDB RDS for MariaDB instance resides.

    RDS instance ID

    Select the ID of the source ApsaraDB RDS for MariaDB instance.

    Database account

    Enter the database account of the source ApsaraDB RDS for MariaDB instance. For information about the required permissions, see Database account permissions.

    Database password

    Enter the password for the database account.

    After you enter the source database information, you can click Test Connectivity next to Database Password to verify that the entered information is correct.

    Note

    If the information is entered correctly, a Passed message is displayed. If a Failed message is displayed, click Diagnose after Failed and follow the prompts to adjust the source database information.

    Destination Database

    Instance type

    Select RDS Instance.

    Instance region

    Select the region where the destination ApsaraDB RDS for MySQL instance resides.

    RDS instance ID

    Select the ID of the destination ApsaraDB RDS for MySQL instance.

    Database account

    Enter the database account of the destination ApsaraDB RDS for MySQL instance. For information about the required permissions, see Database account permissions.

    Database password

    Enter the password for the database account.

    After you enter the destination database information, you can click Test Connectivity after Database Password to verify that the entered information is correct.

    Note

    If the information is entered correctly, 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 first enable SSL encryption for the ApsaraDB RDS for MySQL instance. For more information, see Configure SSL encryption.

    Note

    The Encryption parameter is available only in the Chinese mainland and China (Hong Kong) regions.

  6. After you complete the configurations, click Set Whitelist and Next.

    If the source or destination is an Alibaba Cloud database instance, such as ApsaraDB for MySQL or ApsaraDB for MongoDB, DTS automatically adds the IP addresses of its servers in the corresponding region to the instance's whitelist. If the source or destination is a self-managed database on an ECS instance, DTS automatically adds its IP addresses to the security rules of the ECS instance. You must also ensure that the self-managed database does not restrict access from the ECS instance. If the database is a cluster deployed across multiple ECS instances, you must manually add the DTS IP addresses to the security rules for each ECS instance. If the source or destination is a database in an on-premises data center or on another cloud, you must manually add the DTS IP addresses for the corresponding region to allow access from DTS servers. For a list of DTS server IP addresses, see DTS server IP addresses.

    Warning

    Adding the public CIDR blocks 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, including but not limited to using strong passwords, restricting open ports, using authentication for internal API calls, regularly reviewing and restricting unnecessary network segments, or connecting through private networks such as Express Connect, VPN Gateway, or Smart Access Gateway.

  7. Select the migration types and the objects to migrate.

    Setting

    Description

    Migration types

    • To perform only a full migration, select both Schema Migration and Full Data Migration.

    • To perform a zero-downtime migration, select Schema Migration, Full Data Migration, and Incremental Data Migration.

    Important

    If you do not select Incremental Data Migration, do not write new data to the source database during the full data migration to ensure data consistency.

    Migration objects

    In the Available box, click the objects that you want to migrate and click the 向右小箭头 icon to move them to the Selected Objects box.

    Important
    • You can select objects to migrate at the database, table, and column levels.

    • By default, object names are retained after migration. If you need to rename an object in the destination database, use the object name mapping feature. For more information, see Object name mapping.

    • If you rename an object by using the object name mapping feature, other objects that depend on it may fail to migrate.

    Object name mapping

    If you need to rename a migrated object in the destination instance, use the object name mapping feature. For more information, see Object name mapping.

    Connection retry duration

    If a connection to the source or destination database is interrupted, DTS retries to connect for a default of 720 minutes (12 hours). You can customize this duration. If DTS successfully reconnects within the specified time, the migration task resumes. Otherwise, the task fails.

    Note

    You are charged for the DTS instance while it attempts to reconnect. To avoid unnecessary charges, set an appropriate retry duration or release the DTS instance promptly if the source and destination databases are released.

    Replicate temporary tables created during online DDL operations in DMS

    If you use Data Management (DMS) to perform online DDL operations on the source database, you can choose whether to migrate the temporary tables that are generated.

    • Yes: Migrates the data in the temporary tables that are generated by online DDL operations.

      Note

      If a large amount of temporary table data is generated by online DDL operations, the migration task may experience high latency.

    • No: Does not migrate the data in the temporary tables. Only the original DDL data from the source database is migrated.

      Note

      This option may cause table locks on the destination database.

  8. 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.

  9. After the task passes the precheck, click Next.

  10. 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.

  11. Click Buy and Start to start the migration task.

Stop the migration task

Warning

To minimize the impact of the cutover, you can create a rollback plan to replicate incremental data from the destination database back to the source database in real time. For more information, see Cutover procedure. If no business cutover is involved, you can stop the data migration task.

  • Full data migration

    Do not manually stop a task during full data migration. Otherwise, the system may fail to migrate all data. Wait until the migration task automatically ends.

  • Incremental data migration

    This type of task does not stop automatically; you must stop it manually.

    1. Wait until the task enters the Incremental Data Migration stage with a Undelayed status. Then, stop writes to the source database for a few minutes. During this period, the Incremental Data Migration status might report a latency.
    2. Wait for the Incremental Data Migration status to return to Undelayed. Once this is confirmed in the list, select the task's checkbox and click the StopEnd button in the batch operations bar at the bottom.

What to do next

After the migration is complete, delete the database accounts used for migration from both the ApsaraDB RDS for MariaDB and ApsaraDB RDS for MySQL instances for security purposes. These accounts have read and write permissions.