Data Transmission Service (DTS) supports one-way synchronization from a self-managed PostgreSQL database to an AnalyticDB for PostgreSQL instance, covering both initial full data load and ongoing incremental changes.
Prerequisites
Before you begin, ensure that you have:
Tables to be synchronized with primary keys defined
A destination AnalyticDB for PostgreSQL instance created. For more information, see Create an instance
A database, schema, and table created in the destination instance that match the schema of the source objects. For more information, see SQL syntax
Limitations
| Limitation | Details |
|---|---|
| Scope per task | One task covers one database. Create a separate task for each additional database. |
| Supported objects | Only tables can be selected as synchronization objects. |
| Schema synchronization | Not supported. Create the required schemas in the destination instance manually before starting the task. |
| DDL operations | DDL changes on source objects during synchronization are not automatically replicated. Apply the same DDL to the destination, then restart the task. |
| Supported DML operations | INSERT, UPDATE, DELETE |
| Unsupported data types | BIT, VARBIT, GEOMETRY, UUID, TSQUERY, TSVECTOR, TXID_SNAPSHOT |
Usage notes
New tables created during synchronization
DTS uses PostgreSQL logical replication to capture row-level changes. For UPDATE and DELETE operations to replicate correctly, the write-ahead logging (WAL) logs must include the full row image. Run the following statement on each new table before it can be synchronized:
ALTER TABLE schema.table REPLICA IDENTITY FULL;Without this setting, WAL logs for UPDATE and DELETE operations do not include the full row image, and DTS cannot replicate those changes.
REPLICA IDENTITY FULL increases WAL volume for the affected tables. Apply it selectively to tables that require CDC replication.
Primary/secondary switchover
Switchover is supported only on ApsaraDB RDS for PostgreSQL 11 instances. Before performing a switchover, set the rds_failover_slot_mode parameter to sync. For more information, see Logical Replication Slot Failover.
Performing a primary/secondary switchover on a self-managed PostgreSQL database or an ApsaraDB RDS for PostgreSQL instance of any other version causes the synchronization task to fail.
Long-running transactions
Long-running transactions in the source database cause WAL logs to accumulate until those transactions commit. If left unaddressed, this can exhaust disk space on the source database. Monitor and commit or roll back long-running transactions promptly.
Configure the synchronization task
The end-to-end flow consists of four stages:
Purchase a DTS instance
Open the DTS console and navigate to your synchronization task
Configure source and destination instances, then set the synchronization policy
Run the precheck and start the task
Step 1: Purchase a DTS instance
Purchase a DTS instance. On the buy page, set the following:
| Parameter | Value |
|---|---|
| Source Instance | PostgreSQL |
| Destination Instance | AnalyticDB for PostgreSQL |
| Synchronization Topology | One-Way Synchronization |
Step 2: Open the DTS console
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.
Step 3: Navigate to the synchronization task
In the left-side navigation pane, click Data Synchronization.
Step 4: Select the destination region
At the top of the Synchronization Tasks page, select the region where the destination instance resides.
Step 5: Open the task configuration
Find the synchronization instance and click Configure Task in the Actions column.
Step 6: Configure the source and destination instances
Source instance details
| Parameter | Description |
|---|---|
| Synchronization task name | DTS generates a name automatically. Specify a descriptive name for easy identification. The name does not need to be unique. |
| Instance type | Select based on how your source database is deployed. This example uses User-Created Database in ECS Instance. For other instance types, configure the network environment first. For more information, see Preparation overview. |
| Instance region | The source region selected on the buy page. Read-only. |
| ECS instance ID | Select the Elastic Compute Service (ECS) instance where the self-managed PostgreSQL database is deployed. |
| Database type | PostgreSQL. Read-only. |
| Port number | The service port of the self-managed PostgreSQL database. |
| Database name | The name of the source database. |
| Database account | An account with schema owner permissions. |
| Database password | The password for the database account. |
Destination instance details
| Parameter | Description |
|---|---|
| Instance type | AnalyticDB for PostgreSQL. Read-only. |
| Instance region | The destination region selected on the buy page. Read-only. |
| Instance ID | Select the AnalyticDB for PostgreSQL instance. |
| Database name | The name of the destination database. |
| Database account | The initial account of the AnalyticDB for PostgreSQL instance, or an account with the RDS_SUPERUSER permission. For more information, see Create a database account and Manage users and permissions. |
| Database password | The password for the database account. |
Step 7: Add DTS IP addresses to the whitelist
Click Set Whitelist and Next. DTS automatically adds its server CIDR blocks to the inbound security group rule of the ECS instance and the whitelist of the AnalyticDB for PostgreSQL instance, so DTS can connect to both ends.
Step 8: Configure the synchronization policy and objects
| Parameter | Description |
|---|---|
| Initialize synchronization | Initial Full Data Synchronization is selected by default. After the precheck passes, DTS copies all existing data from the source database to the destination instance as the baseline for incremental synchronization. |
| Processing mode of conflicting tables | Clear Data: Skips the empty-table check and clears destination table data before the full sync. Use this when you want to test the task and then synchronize production data. Ignore: Skips the empty-table check and appends incoming data to existing destination data. Use this when synchronizing from multiple source tables into one destination table. |
| Synchronization type | Select the DML operations to synchronize: Insert, Update, and Delete. The AlterTable option is shown but not supported. |
| Objects to synchronize | Select tables from the Available list and move them to the Selected list using the  icon. Only tables can be selected. To rename objects in the destination, use the object name mapping feature. For more information, see Rename an object to be synchronized and Object name mapping. |
| Retry time for failed connections | Default is 720 minutes (12 hours). If DTS reconnects within this window, the task resumes automatically. Otherwise, the task fails. DTS charges apply during the retry period. Set this value based on your business needs and release the DTS instance promptly if both the source and destination instances are released. |
Step 9: Run the precheck
Click Precheck in the lower-right corner. The task cannot start until the precheck passes.
If any item fails, click the 
icon next to the failed item to view details. After resolving the issue, start a new precheck. If you choose not to fix an issue, ignore the failed item and start a new precheck.
Step 10: Start the task
After the Precheck Passed message appears, close the Precheck dialog box. The synchronization task starts automatically.
Step 11: Verify the task status
Wait for the initial full synchronization to complete. Once finished, the task transitions to the Synchronizing state.
Monitor the task on the Synchronization Tasks page.