All Products
Search
Document Center

Data Transmission Service:Synchronize RDS for MySQL across Alibaba Cloud accounts

Last Updated:Mar 30, 2026

Data Transmission Service (DTS) supports real-time data synchronization between ApsaraDB RDS for MySQL instances in different Alibaba Cloud accounts. This is useful when your architecture spans multiple accounts—for example, separate accounts for development and production, or when consolidating data after an organizational merger.

"Alibaba Cloud account" in this topic refers to a primary Alibaba Cloud account.

Prerequisites

Before you begin, ensure that you have:

  • Created the source and destination ApsaraDB RDS for MySQL instances. See Create an ApsaraDB RDS for MySQL instance

  • Confirmed that the destination instance has more available storage space than the amount used by the source instance

Supported SQL operations

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
Important

RENAME TABLE operations can cause data inconsistency. For example, if the synchronization object is Table A and you rename it to Table B in the source database, Table B will not be synchronized to the destination. To prevent this, add the entire database that contains the table as the synchronization object instead of selecting individual tables.

Synchronization topologies

Four one-way topologies are supported:

  • One-to-one

  • One-to-many

  • Cascade

  • Many-to-one

For topology details and considerations, see Synchronization topologies.

Permissions

Instance Required permissions
Source ApsaraDB RDS for MySQL Read and write permissions on the objects to synchronize. See Create accounts and databases and Modify account permissions.
Destination ApsaraDB RDS for MySQL Read and write permissions on the destination database.
If you synchronize database accounts, the source and destination accounts require additional permissions. See Migrate database accounts for details.

Billing

Synchronization type Pricing
Schema synchronization and full data synchronization Free
Incremental data synchronization Charged. See Billing overview.

Considerations before you start

Performance impact

DTS consumes read and write resources from both the source and destination instances during full data synchronization, which can increase their load. If the database performance is already constrained, this may cause service disruption.

Run the synchronization task during off-peak hours—for example, when CPU utilization on both instances is below 30%.

Additional performance considerations:

  • Slow queries on the source instance, tables without primary keys, or deadlocks on the destination instance can cause DTS to consume significantly more resources.

  • Concurrent INSERT operations during full data synchronization cause table fragmentation in the destination, so the destination tablespace will be larger than the source after full synchronization completes.

  • To limit the impact on the destination database, configure throttling for full data synchronization (QPS to the source database, RPS of full data migration, and data migration speed) and for incremental data synchronization (RPS of incremental data synchronization and data synchronization speed) in the advanced settings.

Data consistency

  • If a source table has no primary key or unique constraint and its columns are not unique, duplicate records may appear in the destination.

  • After synchronization completes (status shows Completed), run ANALYZE TABLE <table_name> to confirm all data was written to the target table. This is important after an HA failover event, where data may exist only in memory.

  • Data generated by changes that do not write to binary logs—such as data restored from physical backups or created by cascade operations—is not synchronized to the destination. If this affects your workload, remove the affected database or table from the synchronization objects and then add it back, provided your business allows it. See Modify synchronization objects.

  • If you write columns with names that differ only in case to the same table in the destination MySQL database, unexpected results may occur because MySQL column names are case-insensitive.

  • DTS periodically runs CREATE DATABASE IF NOT EXISTS \test\`` in the source database to advance the binary log offset.

Binary log requirements

Issues caused by binary log retention periods shorter than DTS requires are not covered under the DTS SLA.

For ApsaraDB RDS for MySQL:

Parameter Required value Notes
Binary logging Enabled Enabled by default on ApsaraDB RDS for MySQL.
binlog_row_image full Required. The precheck fails if this is not set. See Configure instance parameters.
Binary log retention period At least 3 days (7 days recommended) If logs are purged before DTS retrieves them, the task fails and data inconsistency or loss may occur. To configure the retention period, see Automatically delete local logs.

For self-managed MySQL:

Parameter Required value Notes
Binary logging Enabled Must be enabled manually.
binlog_format row Required.
binlog_row_image full Required.
log_slave_updates Enabled Required for dual-primary clusters where both nodes act as primary and secondary. See Create an account and configure binary logging.
Binary log retention period At least 7 days If logs are purged before DTS retrieves them, the task fails and data inconsistency or loss may occur.

Encryption and security

  • Always Encrypted: Full data synchronization is not supported for ApsaraDB RDS for MySQL instances with Always Encrypted enabled.

  • Transparent Data Encryption (TDE): Schema synchronization, full data synchronization, and incremental data synchronization are all supported for instances with TDE enabled.

  • After the cross-account synchronization task completes, delete the RAM role created during the preparation steps.

Other limitations

  • Cross-account and cross-region data synchronization is supported. Cross-account two-way synchronization is supported only between ApsaraDB RDS for MySQL instances.

  • If Replicate Data Across Alibaba Cloud Accounts is set to Yes only for the source database, the account that owns the destination database instance must create the DTS task.

  • You can obtain information about the database instances only after you complete the prerequisite steps.

  • Read-only instances that do not record transaction logs (such as ApsaraDB RDS for MySQL 5.6 read-only instances) cannot serve as source databases.

  • Do not run DDL operations that change database or table schemas during schema synchronization or full data synchronization. Otherwise, the task fails.

    During full data synchronization, DTS queries the source database and creates metadata locks that may block DDL operations on the source database.
  • Resolvers defined by comment syntax do not support synchronous use.

  • If your source database uses online DDL operations in temporary table mode—including multi-table merge scenarios—or adds function-based indexes to unique key columns, data loss or task failure may occur in the destination database.

  • If your data includes four-byte characters (such as rare Chinese characters or emoji), the destination database and table must use the utf8mb4 character set. If DTS synchronizes table schemas, also set the character_set_server parameter to utf8mb4 at the instance level in the destination database.

  • Hidden columns in the objects to synchronize can cause the DTS task to fail or result in data loss. Run ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; to make hidden columns visible before starting the task. See Invisible columns.

  • If a task fails, DTS support staff will attempt to restore it within eight hours by restarting the task or adjusting its parameters (DTS task parameters only, not database parameters). See Modify instance parameters.

Create a cross-account synchronization task

This procedure covers the scenario where the source and destination databases are in different Alibaba Cloud accounts. For general RAM authorization setup, see Configure RAM authorization for cross-account tasks.

Step 1: Configure RAM authorization

Follow Scenario 3: Both the source and destination databases are in different Alibaba Cloud accounts to create RAM roles in both accounts.

Step 2: Open the synchronization task list

Log on with the Alibaba Cloud account designated for creating DTS tasks, then navigate to the data synchronization task list in the destination region using one of the following consoles:

DTS console

  1. Log on to the DTS console.

  2. In the left navigation pane, click Data Synchronization.

  3. In the upper-left corner, select the region where the synchronization instance will be located.

DMS console

The steps may vary depending on the mode and layout of the Data Management (DMS) console. See Simple mode console and Customize the DMS console layout.
  1. Log on to the DMS console.

  2. In the top menu bar, choose Data + AI > DTS (DTS) > Data Synchronization.

  3. To the right of Data Synchronization Tasks, select the region of the synchronization instance.

Step 3: Configure the task

Click Create Task to open the task configuration page.

Warning

After selecting the source and destination instances, carefully review the limits displayed at the top of the page before proceeding.

Configure the source and destination database parameters:

Parameter Description
Task Name DTS generates a name automatically. Specify a descriptive name for easy identification. Names do not need to be unique.
Select Existing Connection Select a registered database instance from the list to auto-fill the connection details, or configure the connection manually. In the DMS console, this is Select a DMS database instance.
Database Type Select MySQL.
Connection Type Select Alibaba Cloud Instance.
Instance Region Select the region where the source (or destination) ApsaraDB RDS for MySQL instance is located. Source and destination instances can be in different regions.
Replicate Data Across Alibaba Cloud Accounts Select Yes for both source and destination.
Alibaba Cloud Account Enter the ID of the Alibaba Cloud account that owns the source (or destination) database. See Obtain the account ID for the source database and Obtain the account ID for the destination database.
RAM Role Name Enter the name of the RAM role created by the account that owns the source (or destination) database, for example, ram-for-dts. See Create a RAM role for the source database and Create a RAM role for the destination database. Do not enter the default DTS system role AliyunDTSDefaultRole.
RDS Instance ID Select the instance ID of the source (or destination) ApsaraDB RDS for MySQL instance. If an alert appears, modify the settings as prompted. See Common errors.
Database Account Enter the database account for the instance.
Database Password Enter the password for the database account.
Encryption Select Non-encrypted or SSL-encrypted. If you select SSL-encrypted, first enable SSL encryption on the RDS instance. See Configure SSL encryption.

After completing the configuration, click Test Connectivity and Proceed.

Make sure the CIDR blocks of the DTS servers are added to the IP address whitelist of both instances. See Add the CIDR blocks of DTS servers. If either instance is a self-managed database, also click Test Connectivity in the CIDR blocks of DTS servers dialog box.

Step 4: Configure synchronization objects

On the Configure Objects page, set the following parameters:

Parameter Description
Synchronization Types Incremental Data Synchronization is selected by default. Also select Schema Synchronization and Full Data Synchronization. After the precheck passes, DTS initializes the full data of the selected objects in the destination instance as the baseline for subsequent incremental data synchronization.
Method to Migrate Triggers in Source Database Select how to handle triggers. See Configure trigger synchronization. Available only when Schema Synchronization is selected.
Enable Migration Assessment Assesses whether source and destination schemas meet synchronization requirements. Selecting Yes may extend the precheck duration. The assessment results are viewable during the precheck and do not affect the precheck outcome. Available only when Schema Synchronization is selected.
Synchronization Topology Select One-way Synchronization for this example.
Processing Mode of Conflicting Tables Precheck and Report Errors: Checks for tables with the same name in the destination. Reports an error during the precheck if any are found, and the task does not start. If you cannot delete or rename the conflicting table, map it to a different name in the destination. See Map object names. Ignore Errors and Proceed: Skips the same-name check. Use with caution—this can cause data inconsistency. During full data synchronization, DTS skips source records that conflict with existing destination records. During incremental data synchronization, DTS overwrites destination records. If table schemas are inconsistent, data initialization may partially or completely fail.
Whether to migrate Event Specify whether to synchronize events from the source database. If you select Yes, meet the relevant requirements and perform subsequent steps. See Synchronize events.
Capitalization of Object Names in Destination Instance Configure the case policy for object names in the destination. The default is the DTS default policy. See Case policy for destination object names.
Source Objects In the Source Objects box, select the objects to synchronize, then click the arrow to move them to the Selected Objects box. Select at the database, table, or column level. If you select only tables or columns, DTS does not synchronize other object types such as views, triggers, and stored procedures.
Selected Objects To rename an object in the destination, right-click it in the Selected Objects box. See Map a single object name. To rename multiple objects in bulk, click Batch Edit. See Map multiple object names in bulk. To filter data with a WHERE clause, right-click a table and set filter conditions. See Set filter conditions.

Click Next: Advanced Settings and configure the following:

Parameter Description
Dedicated Cluster for Task Scheduling DTS uses a shared cluster by default. For greater task stability, purchase a dedicated cluster. See DTS dedicated cluster.
Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database If the source database uses Data Management (DMS) or gh-ost for online DDL changes, choose how to handle temporary tables. Yes: Synchronizes temporary tables. If they are large, synchronization latency may increase. No, Adapt to DMS Online DDL: Does not synchronize temporary tables—synchronizes only the original DDL statements run in DMS. This causes table locks on the destination. No, Adapt to gh-ost: Does not synchronize temporary tables—synchronizes only the original DDL statements run by gh-ost. This causes table locks on the destination.
Note

DTS does not support online DDL changes made by pt-online-schema-change. Using this tool will cause the DTS task to fail.

Whether to Migrate Accounts Specify whether to synchronize account information from the source database. If you select Yes, also select the accounts to synchronize and confirm their permissions.
Retry Time for Failed Connections If the connection to the source or destination database fails after the task starts, DTS retries immediately. The default retry duration is 720 minutes. Set a value between 10 and 1,440 minutes; 30 minutes or more is recommended. If the connection is restored within this period, the task resumes automatically.
Note

If multiple DTS instances share a source or destination database, DTS uses the shortest configured retry duration for all instances. DTS charges for task runtime during connection retries.

Retry Time for Other Issues If a non-connection issue occurs (for example, a DDL or DML execution error), DTS retries immediately. The default retry duration is 10 minutes. Set a value between 1 and 1,440 minutes; 10 minutes or more is recommended. This value must be less than Retry Time for Failed Connections.
Enable Throttling for Full Data Synchronization Set QPS to the source database, RPS of full data migration, and data migration speed (MB/s) to limit the load on the destination during full data synchronization. Available only when Full Data Synchronization is selected. You can also adjust the rate while the task is running.
Enable Throttling for Incremental Data Synchronization Set RPS of incremental data synchronization and data synchronization speed (MB/s) to limit load during incremental data synchronization.
Environment Tag (Optional) Assign an environment tag to identify the instance.
Configure ETL Choose whether to enable the extract, transform, and load (ETL) feature. See What is ETL? and Configure ETL.
Whether to delete SQL operations on heartbeat tables of forward and reverse tasks Yes: DTS does not write heartbeat SQL to the source database. The DTS instance may display latency. No: DTS writes heartbeat SQL to the source database. This may interfere with source database operations like physical backups and cloning.
Monitoring and Alerting Configure alerts to receive notifications when the task fails or latency exceeds a threshold. See Configure monitoring and alerting.

Click Data Verification to configure a data verification task. See Configure data verification.

Step 5: Run the precheck

Click Next: Save Task Settings and Precheck.

To review the API parameters for this configuration, hover over the button and click Preview OpenAPI parameters in the tooltip.

Before the task starts, DTS runs a precheck automatically.

  • If the precheck fails, click View Details next to the failed item, fix the issue, and rerun the precheck.

  • If the precheck generates warnings:

    • For non-ignorable warnings, click View Details, fix the issue, and rerun the precheck.

    • For ignorable warnings, click Confirm Alert Details > Ignore > OK, then click Precheck Again. Ignoring warnings may cause data inconsistency. Proceed with caution.

Step 6: Purchase the synchronization instance

  1. When the Success Rate reaches 100%, click Next: Purchase Instance.

  2. On the Purchase page, select the billing method and instance class:

    Parameter Description
    Billing Method Subscription: Pay upfront for a fixed duration. Suitable for long-term, continuous tasks. Pay-as-you-go: Billed hourly for actual usage. Suitable for short-term or test tasks—release the instance at any time to stop billing.
    Resource Group Settings The resource group for the instance. The default is the default resource group. See What is Resource Management?.
    Instance Class Select the specification based on your synchronization throughput requirements. Higher specifications support faster synchronization rates. See Data synchronization link specifications.
    Subscription Duration For subscription billing only. Monthly options: 1–9 months. Yearly options: 1, 2, 3, or 5 years.
  3. Read and accept the Data Transmission Service (Pay-as-you-go) Service Terms.

  4. Click Buy and Start, then click OK to confirm.

The task starts and you can monitor its progress on the data synchronization page.

What's next

After the synchronization task is running:

  • Monitor synchronization latency and task status on the data synchronization page.

  • When synchronization completes (status shows Completed), run ANALYZE TABLE <table_name> on the destination to confirm all data was written correctly.

  • Delete the RAM role created during the preparation steps, as it is no longer needed.