Use Data Transmission Service (DTS) to synchronize data from a PolarDB for MySQL cluster to an AnalyticDB for MySQL cluster. Once synchronization is running, you can use AnalyticDB for MySQL to build business intelligence (BI) systems, interactive query systems, and real-time reporting systems without impacting your PolarDB for MySQL production workload.
Prerequisites
Before you begin, make sure that you have:
-
An AnalyticDB for MySQL cluster with enough storage for the data to be synchronized. See Create an AnalyticDB for MySQL cluster.Create an AnalyticDB for MySQLEnable binlogcluster
-
Binary logging enabled for the PolarDB for MySQL cluster. See Enable binary logging.
Billing
| Synchronization type | Cost |
|---|---|
| Schema synchronization and full data synchronization | Free |
| Incremental data synchronization | Charged. For details, see Billing overview. |
Supported SQL operations
DTS can synchronize the following SQL operations:
-
DDL: CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE, ADD COLUMN, DROP COLUMN, MODIFY COLUMN
-
DML: INSERT, UPDATE, DELETE
If you change the data type of a field in a source table during data synchronization, the synchronization job reports an error and stops. You can fix the issue manually. For more information, see Fix a synchronization failure caused by a data type change.
If a field's data type changes during synchronization, DTS reports an error and stops the task. For troubleshooting steps, see Troubleshoot the synchronization failure that occurs due to field type changes.
Required permissions
| Database | Required permission |
|---|---|
| PolarDB for MySQL cluster | Read permissions on the objects to be synchronized |
| AnalyticDB for MySQL | Read and write permissions on the required objects |
To create and authorize database accounts, see Create a database account for AnalyticDB for MySQLCreate a database account for PolarDB for MySQL and .
Data type mappings
For data type mappings between PolarDB for MySQL and AnalyticDB for MySQL, see Data type mappings for schema synchronization.
Limitations
Review the following limitations before starting synchronization:
-
Performance impact: DTS reads from the source cluster and writes to the destination cluster during initial full data synchronization, which increases load on both instances. If the source cluster has many slow queries, tables without primary keys, or the destination cluster encounters deadlocks, the performance impact is amplified. Schedule synchronization during off-peak hours when CPU utilization on both instances is below 30%.
-
DDL tool restriction: Do not use gh-ost or pt-online-schema-change to perform DDL operations during synchronization. These tools may cause synchronization failures.
-
Destination disk space threshold: AnalyticDB for MySQL locks the cluster when any node's disk usage exceeds 80%. Estimate the required disk space before starting synchronization and make sure the destination cluster has sufficient storage.
-
Prefix index limitation: DTS cannot synchronize prefix indexes. For example, an index defined as
CREATE INDEX idx ON table_name (column_name(10))is not synchronized. If the source cluster contains prefix indexes, data may fail to be synchronized.
Set up data synchronization
Step 1: Purchase a DTS instance
Purchase a data synchronization instance. On the buy page, set the following options:
-
Source Instance: PolarDB
-
Target Instance: AnalyticDB for MySQL
-
Synchronization Topology: One-way Synchronization
Step 2: Configure the synchronization task
-
Log on to the DTS console.
If you are redirected to the Data Management (DMS) console, click the
icon in the
to switch to the previous version of the DTS console. -
In the left-side navigation pane, click Data Synchronization.
-
At the top of the Synchronization Tasks page, select the region where the destination instance resides.
-
Find the data synchronization instance and click Configure Task in the Actions column.
-
Configure the source and destination clusters.
Section Parameter Description N/A Synchronization Task Name An auto-generated name. Specify a descriptive name to identify the task. The name does not need to be unique. Source Instance Details Instance Type Set to PolarDB Instance. This value cannot be changed. Instance Region The source region you selected on the buy page. This value cannot be changed. PolarDB Instance ID The ID of the source PolarDB for MySQL cluster. Database Account The database account of the source cluster. See Required permissions. Database Password The password of the source database account. Destination Instance Details Instance Type Set to AnalyticDB. This value cannot be changed. Instance Region The destination region you selected on the buy page. This value cannot be changed. Version Select 3.0. Database The ID of the destination AnalyticDB for MySQL cluster. Database Account The account of the AnalyticDB for MySQL database. See Required permissions. Database Password The password of the destination database account. 
-
Click Set Whitelist and Next. DTS automatically adds its server CIDR blocks to the IP address whitelist of Alibaba Cloud database instances. For self-managed databases on Elastic Compute Service (ECS) instances, DTS automatically adds its CIDR blocks to the ECS security group rules—make sure the ECS instance can connect to the database. If the database runs on multiple ECS instances, manually add DTS CIDR blocks to each instance's security group rules. For on-premises databases or databases from third-party cloud providers, manually add DTS CIDR blocks to the IP address whitelist. For details, see Add the CIDR blocks of DTS servers.
WarningAdding DTS CIDR blocks to your whitelist or security group rules introduces security risks. Before proceeding, take preventive measures such as using strong credentials, restricting exposed ports, authenticating API calls, auditing whitelist and security group rules regularly, and blocking unauthorized CIDR blocks. Alternatively, connect the database to DTS using Express Connect, VPN Gateway, or Smart Access Gateway.
-
Select the synchronization policy and objects.
Parameter Description Select the initial synchronization types Select both Initial Schema Synchronization and Initial Full Data Synchronization. After the precheck completes, DTS synchronizes the schema and data of the selected objects. This is required for subsequent incremental synchronization. Processing Mode In Existed Target Table Precheck and Report Errors (default): Checks for tables with identical names in both databases. If the destination already has tables with the same names, the precheck fails and the task cannot start. To resolve naming conflicts, use the object name mapping feature. See Rename an object to be synchronized. Ignore Errors and Proceed: Skips the precheck for identical table names. If schemas match, DTS skips rows whose primary keys already exist in the destination. If schemas differ, only matching columns are synchronized, or the task fails. > WarningSelecting Ignore Errors and Proceed may cause data inconsistency.
Merge Multi Tables Yes: Adds a __dts_data_sourcecolumn to each table to track data sources. DDL operations cannot be synchronized when this option is enabled. To merge only some source tables, create separate synchronization tasks. No (default): DDL operations can be synchronized.Select the operation types to be synchronized Select the operation types based on your requirements. All types are selected by default. See Supported SQL operations. Select the objects to be synchronized In the Available section, select one or more tables or databases, then click the
icon to move them to the Selected section. Selecting a database synchronizes all schema changes in that database. Selecting a table synchronizes only ADD COLUMN operations on that table. Object names remain unchanged in the destination by default. To rename objects, use the object name mapping feature. See Rename an object to be synchronized.Rename Databases and Tables Rename objects in the destination instance using the object name mapping feature. See Object name mapping. Replicate Temporary Tables When DMS Performs DDL Operations Applies when using DMS for online DDL operations. Yes: DTS synchronizes temporary tables generated by online DDL operations. Large online DDL operations may delay synchronization. No: DTS synchronizes only the original DDL data, not temporary tables. Destination tables may be locked during this process. Retry Time for Failed Connections DTS retries failed connections for 720 minutes (12 hours) by default. If DTS reconnects within the retry window, synchronization resumes. Otherwise, the task fails. Note that you are charged for the DTS instance during retries. Specify the retry time based on your business needs. You can also release the DTS instance at your earliest opportunity after the source and destination instances are released. 
-
Click Next.
-
Specify the table type for each table to synchronize to the destination AnalyticDB for MySQL cluster.Select 3.0.
When Initial Schema Synchronization is selected, you must specify the type, primary key column, and partition key column for each table. For details, see CREATE TABLE.

-
Click Precheck. DTS runs a precheck before starting the synchronization task. The task can only start after the precheck passes. If any precheck item fails, click the
icon next to the failed item to view details. Fix the issue and run the precheck again. If you choose not to fix an item, ignore it and run the precheck again. -
After the Precheck Passed message appears, close the Precheck dialog box. The synchronization task starts automatically.
-
On the Synchronization Tasks page, wait for the task state to change to Synchronizing.

What's next
After the task enters the Synchronizing state, the data in AnalyticDB for MySQL stays up to date with the source PolarDB for MySQL cluster. You can now:
-
Build BI dashboards and reports using the data in AnalyticDB for MySQL.
-
Run interactive queries on the destination cluster without impacting the PolarDB for MySQL production workload.
-
Monitor synchronization task status on the Synchronization Tasks page.