Data Transmission Service:Synchronize data from an ApsaraDB RDS for MySQL instance to a self-managed Oracle database

Source database

Tables must have a primary key or unique key constraint. All fields must be unique. Without this, the destination database may contain duplicate records.

Binary logging must be correctly configured:

• For ApsaraDB RDS for MySQL: binary logging is enabled by default. Set binlog_row_image to full. If this parameter is not set correctly, the precheck fails and the task cannot start. For details, see Modify instance parameters.

• For self-managed MySQL: enable binary logging, set binlog_format to row, and set binlog_row_image to full.

• For self-managed MySQL in a dual-primary cluster: also set log_slave_updates to ON to make sure DTS can obtain all binary logs. For details, see Create an account for a self-managed MySQL database and configure binary logging.

Binary log retention must meet minimum requirements. If binary logs are purged before DTS reads them, the task fails and data inconsistency or loss may occur:

• ApsaraDB RDS for MySQL: retain binary logs for at least 3 days (7 days recommended). For details, see the Delete binary log files section in "Manage binary log files".

• Self-managed MySQL: retain binary logs for at least 7 days.

Object count limit when synchronizing individual tables with edits: If you select tables as objects to synchronize and want to rename tables or columns, a single task supports up to 1,000 tables. For more than 1,000 tables, configure multiple tasks or synchronize the entire database instead.

Do not run DDL statements during schema synchronization or full data synchronization. Doing so causes the task to fail.

MySQL 8.0.23 or later: invisible columns are not synchronized. If the source includes invisible columns, data loss occurs. To make a column visible, run:

ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;

For tables without a primary key, MySQL 8.0.23 or later automatically generates an invisible primary key. Make the invisible primary key visible before starting the synchronization task. For details, see Invisible columns and Generated invisible primary keys.

Data generated by physical backup restores or cascade operations is not synchronized. If unsynchronized data causes issues, remove the affected tables from the synchronization objects, then re-add them. For details, see Modify the objects to be synchronized.

Cascaded UPDATE or DELETE operations may cause data inconsistency during full data synchronization and incremental data synchronization. DTS does not capture the cascaded changes on child tables triggered by parent table operations.

Destination database

Disable foreign keys and triggers on the destination database before starting the task. If either is active during full data synchronization and incremental data synchronization, the synchronization task may fail.

Oracle RAC as destination: use a single VIP, not the SCAN IP. After specifying the VIP, node failover is not supported for the Oracle RAC database.

Other limitations

• At most one column attribute can be changed.

• Basic data types cannot be changed.

• ApsaraDB RDS for MySQL with EncDB enabled: full data synchronization is not supported.

• ApsaraDB RDS for MySQL with Transparent Data Encryption (TDE) enabled: schema synchronization, full data synchronization, and incremental data synchronization are all supported.

• If a DTS task fails, DTS technical support attempts to restore it within 8 hours. During restoration, the task may be restarted and task parameters may be modified (database parameters are not modified). The parameters that may be modified include but are not limited to the parameters in the Modify instance parameters section of the Modify the parameters of a DTS instance topic.

Special cases

Self-managed MySQL: a primary/secondary switchover during the task causes failure. Plan switchovers around the synchronization task window.

Read-only ApsaraDB RDS for MySQL 5.6 (no transaction logs) cannot be used as a source.

Synchronization latency may be inaccurate when no DML operations occur on the source. If the reported latency is too high, perform a DML operation on the source to update it. To maintain accurate latency automatically, create a heartbeat table (updated every second) when synchronizing an entire database.

DTS periodically executes `CREATE DATABASE IF NOT EXISTS 'test'` on the source to advance the binary log file position. This applies to both ApsaraDB RDS for MySQL and self-managed MySQL sources.

Step 1: Go to the Data Synchronization page

Use one of the following methods:

DTS console

1. Log on to the DTS console.

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

3. In the upper-left corner, select the region where the synchronization instance resides.

DMS console

The actual operations may vary based on the mode and layout of the DMS console. For details, see Simple mode and Customize the layout and style of the DMS console.

1. Log on to the DMS console.

2. In the top navigation bar, move the pointer over Data + AI and choose DTS (DTS) > Data Synchronization.

3. From the drop-down list next to Data Synchronization Tasks, select the region where the synchronization instance resides.

Step 2: Configure source and destination databases

1. Click Create Task.

2. Configure the parameters described in the following tables.

General

Source database

Destination database

1. Click Test Connectivity and Proceed. In the CIDR Blocks of DTS Servers dialog box, click Test Connectivity.

Make sure the CIDR blocks of DTS servers are added to the security settings of both the source and destination databases. For details, see Add the CIDR blocks of DTS servers.

Step 3: Configure objects to synchronize

1. In the Configure Objects step, configure the following parameters.

1. Click Next: Advanced Settings and configure the following parameters.

1. Click Next Step: Data Verification to configure data verification. For details, see Configure a data verification task.

Step 4: Run the precheck

1. Click Next: Save Task Settings and Precheck.

   To view the API parameters for this configuration, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.

2. Wait for the precheck to complete.

   • If an item fails, click View Details, fix the issue, then click Precheck Again.

   • If an item returns an alert that can be ignored, click Confirm Alert Details, then click Ignore > OK > Precheck Again. Ignoring alert items may cause data inconsistency.

Step 5: Purchase and start the instance

1. Wait until Success Rate reaches 100%, then click Next: Purchase Instance.

2. On the buy page, configure the following parameters.

1. Read and select Data Transmission Service (Pay-as-you-go) Service Terms.

2. Click Buy and Start, then click OK in the dialog box.

The task appears in the task list. Monitor its progress from there.