How to migrate data from PolarDB for PostgreSQL to RDS for PostgreSQL - Data Transmission Service

This topic describes how to use Data Transmission Service (DTS) to migrate data from a PolarDB for PostgreSQL cluster to an ApsaraDB RDS for PostgreSQL instance.

Prerequisites

A source PolarDB for PostgreSQL cluster is created. For more information, see Create a database cluster.
A destination ApsaraDB RDS for PostgreSQL instance is created. For more information, see Create an RDS for PostgreSQL instance.
The wal_level parameter of the source PolarDB for PostgreSQL cluster is set to logical. For more information about how to set the parameter, see Set cluster parameters.
The storage space of the destination database must be greater than the storage space used by the source database.

Notes

Note

During schema migration, DTS migrates foreign keys from the source database to the destination database.
During full data migration and incremental data migration, DTS temporarily disables the constraint check and cascade operations on foreign keys at the session level. If you perform the cascade update and delete operations on the source database during data migration, data inconsistency may occur.

Type	Description
Source database limits	In the PolarDB for PostgreSQL cluster, the tables to be migrated must have primary keys or non-empty unique indexes. If the source database has long-running transactions and the instance includes an incremental migration task, the write-ahead log (WAL) generated before the long-running transactions are committed may not be cleared and may accumulate. This can cause insufficient disk space in the source database. To ensure that the migration task runs as expected and to prevent logical subscriptions from being interrupted by a primary/secondary switchover, the PolarDB for PostgreSQL cluster must support and enable Logical Replication Slot Failover. Note If the source PolarDB for PostgreSQL cluster does not support the logical replication slot failover feature (for example, when the Database Engine is PostgreSQL 14), a high-availability (HA) switchover in the source database may cause the migration instance to fail and become unrecoverable. Limits on operations in the source database: During schema migration and full data migration, do not perform DDL operations that change the schema of a database or table. Otherwise, the data migration task fails. If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency occurs between the source and destination databases. To ensure data consistency in real time, select schema migration, full data migration, and incremental data migration. Due to the limits on logical subscriptions in the source database, if a single piece of data to be migrated from the source database exceeds 256 MB after an incremental change during the running of a migration instance that includes an incremental task, the migration instance may fail and cannot be recovered. You need to reconfigure the migration instance.
Other limits	A single data migration task can migrate only one database. If you want to migrate multiple databases, you must configure a data migration task for each database. DTS does not support migrating TimescaleDB extension tables or tables with cross-schema inheritance relationships. If the migration instance includes an incremental data migration task, you must run the `ALTER TABLE schema.table REPLICA IDENTITY FULL;` command on the table to be migrated in the source database before you write data to it in the following two scenarios. This ensures data consistency for the table migration. During the execution of this command, we recommend that you do not perform table locking operations. Otherwise, the table will be locked. If you skip the relevant check in the precheck, DTS automatically runs this command when the instance is initialized. When the instance runs for the first time. When the migration object granularity is Schema, and a new table is created in the schema to be migrated or a table to be migrated is rebuilt using the RENAME command. Note In the command, replace `schema` and `table` with the schema name and table name of the data to be migrated. We recommend that you perform this operation during off-peak hours. If a table to be migrated contains a field of the SERIAL type, the source database automatically creates a Sequence for the field. Therefore, when you configure the Source Objects, if the Migration Types is set to Schema Migration, we recommend that you also select Sequence or migrate the entire schema. Otherwise, the migration instance may fail. During full data migration, concurrent INSERT operations cause fragmentation in the tables of the destination database. After full data migration is complete, the table storage space in the destination database is larger than that in the source instance. DTS attempts to resume failed migration tasks within seven days. Before you switch your workloads to the destination instance, you must end or release the task. You can also run the `revoke` command to revoke the write permissions of the account that DTS uses to access the destination instance. This prevents the source data from overwriting the data in the destination instance after the task is automatically resumed. DTS validates data content but does not validate metadata such as sequences. You must validate the metadata yourself. During incremental data migration, DTS creates a replication slot with the prefix `dts_sync_` in the source database to replicate data. DTS can use this replication slot to obtain incremental logs from the source database within 15 minutes. Note DTS automatically deletes the replication slot after the instance is released. If you change the database password or delete the DTS IP address from the whitelist during migration, the replication slot cannot be automatically deleted. In this case, you must manually delete the replication slot from the source database to prevent it from accumulating and occupying disk space, which can make the ApsaraDB RDS for PostgreSQL instance unavailable. When a migration task is released or fails, DTS automatically clears the replication slot. If a primary/secondary failover occurs on the ApsaraDB RDS for PostgreSQL instance, you need to log on to the secondary database to manually clear the replication slot. After you switch your business to the destination instance, the newly written sequence does not increment from the maximum value of the sequence in the source database. You need to update the sequence value in the destination database before the business switchover. For more information, see Update the sequence value in the destination database. DTS creates the following temporary tables in the source database to obtain information such as the DDL statements of incremental data, the structure of incremental tables, and heartbeat information. Do not delete these temporary tables from the source database during migration. Otherwise, the DTS task becomes abnormal. The temporary tables are automatically deleted after the DTS instance is released. `public.dts_pg_class`, `public.dts_pg_attribute`, `public.dts_pg_type`, `public.dts_pg_enum`, `public.dts_postgres_heartbeat`, `public.dts_ddl_command`, `public.dts_args_session`, and `public.aliyun_dts_instance`. For a full migration or incremental migration task, if the tables to be migrated in the source database contain foreign keys, triggers, or event triggers, and the destination database account is a privileged account or an account with superuser permissions, DTS temporarily sets the session_replication_role parameter to replica at the session level during full or incremental migration. If the destination database account does not have this permission, you must manually set the session_replication_role parameter to replica in the destination database. During this period (when the session_replication_role parameter is set to replica during full or incremental migration), if there are cascade update or delete operations in the source database, data inconsistency may occur. After the DTS migration task is released, you can change the value of the session_replication_role parameter back to origin. If an instance fails, DTS helpdesk will try to recover the instance within 8 hours. During the recovery process, operations such as restarting the instance and adjusting parameters may be performed. Note When parameters are adjusted, only the parameters of the DTS instance are modified. The parameters of the database are not modified. The parameters that may be modified include but are not limited to those described in Modify instance parameters. When you migrate partitioned tables, you must include both the child partitions and the parent table as synchronization objects. Otherwise, data inconsistency may occur for the partitioned table. Note The parent table of a PostgreSQL partitioned table does not directly store data. All data is stored in the child partitions. The synchronization task must include the parent table and all its child partitions. Otherwise, data in the child tables may be missed, which leads to data inconsistency between the source and destination databases.

Billing

Migration type	Instance configuration fee	Internet traffic fee
Schema migration and full data migration	Free of charge.	When the Access Method parameter of the destination database is set to Public IP Address, you are charged for Internet traffic. For more information, see Billing overview.
Incremental data migration	Charged. For more information, see Billing overview.

Migration types

Schema migration
DTS migrates the schemas of the selected objects from the source database to the destination database.
Full data migration
DTS migrates the historical data of required objects from the source database to the destination database.
Incremental data migration
After full data migration is complete, DTS migrates incremental data from the source database to the destination database. Incremental data migration allows data to be migrated smoothly without interrupting the services of self-managed applications during data migration.

Supported objects to be migrated

SCHEMA and TABLE.
Note
Including PRIMARY KEY, UNIQUE KEY, FOREIGN KEY, DATATYPE (built-in data type), and DEFAULT CONSTRAINT.
VIEW, PROCEDURE (PostgreSQL V11 or later.), FUNCTION, RULE, SEQUENCE, EXTENSION, TRIGGER, AGGREGATE, INDEX, OPERATOR, and DOMAIN.

SQL operations that support incremental migration

Operation type	SQL operation
DML	INSERT, UPDATE, and DELETE
DDL	DDL operations can be migrated only in data migration tasks that are created after October 1, 2020. Important For data migration tasks created before May 12, 2023, you must create a trigger and a function in the source database to capture DDL information before you configure the task. For more information, see Use triggers and functions to implement incremental DDL migration for PostgreSQL. Data of the bit type is not supported during incremental data migration. If the source database account is a privileged account, the following DDL operations are supported in migration tasks: CREATE TABLE and DROP TABLE ALTER TABLE, including RENAME TABLE, ADD COLUMN, ADD COLUMN DEFAULT, ALTER COLUMN TYPE, DROP COLUMN, ADD CONSTRAINT, ADD CONSTRAINT CHECK, and ALTER COLUMN DROP DEFAULT TRUNCATE TABLE (The source PostgreSQL version must be PostgreSQL 11 or later.) CREATE INDEX ON TABLE Important Additional information in DDL statements, such as CASCADE or RESTRICT, is not supported. DDL statements in a session where the `SET session_replication_role = replica` command is run are not supported. DDL statements that are run by calling a FUNCTION or other methods are not supported. If multiple SQL statements submitted from the source database at one time contain both DML and DDL statements, the DDL statements are not migrated. If multiple SQL statements submitted from the source database at one time contain DDL statements for objects that are not to be migrated, the DDL statements are not migrated.

Database account permissions

Database	Schema migration	Full migration	Incremental migration	How to create and grant permissions to an account
PolarDB for PostgreSQL	Privileged account			Create a database account
RDS for PostgreSQL	CREATE and USAGE permissions on the migration objects	Schema owner permissions	Schema owner permissions	Create an account

Procedure

Use one of the following methods to go to the Data Migration page and select the region in which the data migration instance resides.
DTS console
1. Log on to the DTS console.
2. In the left-side navigation pane, click Data Migration.
3. In the upper-left corner of the page, select the region in which the data migration instance resides.
DMS console
Note
The actual operation may vary based on the mode and layout of the DMS console. For more information, 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 > DTS (DTS) > Data Migration.
3. From the drop-down list to the right of Data Migration Tasks, select the region in which the data synchronization instance resides.
Click Create Task to go to the task configuration page.

Configure the source and destination databases. The following table describes the parameters.

Category	Configuration	Description
None	Task Name	The name of the DTS task. DTS automatically generates a task name. We recommend that you specify a descriptive name that makes it easy to identify the task. You do not need to specify a unique task name.
Source Database	Database Type	Select PolarDB for PostgreSQL.
	Access Method	Select Cloud Instance.
	Instance Region	Select the region where the PolarDB for PostgreSQL cluster resides.
	Across Alibaba Cloud Accounts	This example migrates data within the same Alibaba Cloud account. Select No.
	Instance ID	Select the ID of the destination PolarDB for PostgreSQL cluster.
	Database Name	Enter the name of the PolarDB for PostgreSQL database.
	Database Account	Enter the database account of the PolarDB for PostgreSQL cluster.
	Database Password	The password that is used to access the database.
Destination Database	Database Type	Select PostgreSQL.
	Access Method	Select Cloud Instance.
	Instance Region	Select the region where the destination RDS for PostgreSQL instance resides.
	Instance ID	Select the ID of the destination RDS for PostgreSQL instance.
	Database Name	Enter the name of the database in the destination RDS for PostgreSQL instance where the migration objects belong.
	Database Account	Enter the database account of the destination RDS for PostgreSQL instance.
	Database Password	The password that is used to access the database.
	Encryption	Specifies whether to encrypt the connection to the source database. You can configure this parameter based on your business requirements. In this example, Non-encrypted is selected. If you want to establish an SSL-encrypted connection to the source database, perform the following steps: Select SSL-encrypted, upload CA Certificate, Client Certificate, and Private Key of Client Certificate as needed, and then specify Private Key Password of Client Certificate. Note If you set Encryption to SSL-encrypted for a self-managed PostgreSQL database, you must upload CA Certificate. If you want to use the client certificate, you must upload Client Certificate and Private Key of Client Certificate and specify Private Key Password of Client Certificate. For information about how to configure SSL encryption for an ApsaraDB RDS for PostgreSQL instance, see SSL encryption.

Click Test Connectivity and Proceed in the lower part of the page.
Note
- Make sure that the CIDR blocks of DTS servers can be automatically or manually added to the security settings of the source and destination databases to allow access from DTS servers. For more information, see Add DTS server IP addresses to a whitelist.
- If the source or destination database is a self-managed database and its Access Method is not set to Alibaba Cloud Instance, click Test Connectivity in the CIDR Blocks of DTS Servers dialog box.

Configure the objects to be migrated.

On the Configure Objects page, configure the objects that you want to migrate.

Configuration	Description
Migration Types	To perform only full data migration, select Schema Migration and Full Data Migration. To ensure service continuity during data migration, select Schema Migration, Full Data Migration, and Incremental Data Migration. Note If you do not select Schema Migration, make sure a database and a table are created in the destination database to receive data and the object name mapping feature is enabled in Selected Objects. If you do not select Incremental Data Migration, we recommend that you do not write data to the source database during data migration. This ensures data consistency between the source and destination databases.
Processing Mode of Conflicting Tables	Precheck and Report Errors: checks whether the destination database contains tables that use the same names as tables in the source database. If the source and destination databases do not contain tables that have identical table names, the precheck is passed. Otherwise, an error is returned during the precheck and the data migration task cannot be started. Note If the source and destination databases contain tables with identical names and the tables in the destination database cannot be deleted or renamed, you can use the object name mapping feature to rename the tables that are migrated to the destination database. For more information, see Map object names. Ignore Errors and Proceed: skips the precheck for identical table names in the source and destination databases. Warning If you select Ignore Errors and Proceed, data inconsistency may occur and your business may be exposed to the following potential risks: If the source and destination databases have the same schema, and a data record has the same primary key as an existing data record in the destination database, the following scenarios may occur: During full data migration, DTS does not migrate the data record to the destination database. The existing data record in the destination database is retained. During incremental data migration, DTS migrates the data record to the destination database. The existing data record in the destination database is overwritten. If the source and destination databases have different schemas, only specific columns are migrated or the data migration task fails. Proceed with caution.
Capitalization of Object Names in Destination Instance	The capitalization of database names, table names, and column names in the destination instance. By default, DTS default policy is selected. You can select other options to make sure that the capitalization of object names is consistent with that of the source or destination database. For more information, see Specify the capitalization of object names in the destination instance.
Source Objects	Select one or more objects from the Source Objects section. Click the icon to add the objects to the Selected Objects section. Note You can select schemas or tables as the objects to be migrated. If you select tables as the objects to be migrated, DTS does not migrate other objects, such as views, triggers, and stored procedures, to the destination database. If a table to be migrated contains SERIAL data type, and you select Migration Types as Schema Migration, we recommend that you also select Sequence or entire schema migration.
Selected Objects	To rename an object that you want to migrate to the destination instance, right-click the object in the Selected Objects section. For more information, see the Map the name of a single object section of the Map object names topic. To rename multiple objects at a time, click Batch Edit in the upper-right corner of the Selected Objects section. For more information, see the Map multiple object names at a time section of the Map object names topic. Note If you use the object name mapping feature to rename an object, other objects that depend on the object may fail to be migrated.

Click Next: Advanced Settings to configure advanced settings.

Configuration	Description
Dedicated Cluster for Task Scheduling	By default, DTS schedules the data migration task to the shared cluster if you do not specify a dedicated cluster. If you want to improve the stability of data migration tasks, purchase a dedicated cluster. For more information, see What is a DTS dedicated cluster.
Retry Time for Failed Connections	The retry time range for failed connections. If the source or destination database fails to be connected after the data migration task is started, DTS immediately retries a connection within the retry time range. Valid values: 10 to 1,440. Unit: minutes. Default value: 720. We recommend that you set the parameter to a value greater than 30. If DTS is reconnected to the source and destination databases within the specified retry time range, DTS resumes the data migration task. Otherwise, the data migration task fails. Note If you specify different retry time ranges for multiple data migration tasks that share the same source or destination database, the value that is specified later takes precedence. When DTS retries a connection, you are charged for the DTS instance. We recommend that you specify the retry time range based on your business requirements. You can also release the DTS instance at the earliest opportunity after the source database and destination instance are released.
Retry Time for Other Issues	The retry time range for other issues. For example, if DDL or DML operations fail to be performed after the data migration task is started, DTS immediately retries the operations within the retry time range. Valid values: 1 to 1440. Unit: minutes. Default value: 10. We recommend that you set the parameter to a value greater than 10. If the failed operations are successfully performed within the specified retry time range, DTS resumes the data migration task. Otherwise, the data migration task fails. Important The value of the Retry Time for Other Issues parameter must be smaller than the value of the Retry Time for Failed Connections parameter.
Enable Throttling for Full Data Migration	Specifies whether to enable throttling for full data migration. During full data migration, DTS uses the read and write resources of the source and destination databases. This may increase the loads of the database servers. You can enable throttling for full data migration based on your business requirements. To configure throttling, you must configure the Queries per second (QPS) to the source database, RPS of Full Data Migration, and Data migration speed for full migration (MB/s) parameters. This reduces the loads of the destination database server. Note You can configure this parameter only if you select Full Data Migration for the Migration Types parameter.
Enable Throttling for Incremental Data Migration	Specifies whether to enable throttling for incremental data migration. To configure throttling, you must configure the RPS of Incremental Data Migration and Data migration speed for incremental migration (MB/s) parameters. This reduces the loads of the destination database server. Note You can configure this parameter only if you select Incremental Data Migration for the Migration Types parameter.
Environment Tag	You can select an environment tag to identify the instance as needed. In this example, you do not need to select a tag.
Configure ETL	Specifies whether to enable the extract, transform, and load (ETL) feature. For more information, see What is ETL? Valid values: Yes: configures the ETL feature. You can enter data processing statements in the code editor. For more information, see Configure ETL in a data migration or data synchronization task. No: does not configure the ETL feature.
Monitoring and Alerting	Specifies whether to configure alerting for the data migration task. If the task fails or the migration latency exceeds the specified threshold, the alert contacts receive notifications. Valid values: No: does not configure alerting. Yes: configures alerting. In this case, you must also configure the alert threshold and alert notification settings. For more information, see the Configure monitoring and alerting when you create a DTS task section of the Configure monitoring and alerting topic.

Click Next Step: Data Verification to configure the data verification task.
For more information about how to use the data verification feature, see Configure a data verification task.

Save the task settings and run a precheck.
- To view the parameters to be specified when you call the relevant API operation to configure the DTS task, move the pointer over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.
- If you do not need to view or have viewed the parameters, click Next: Save Task Settings and Precheck in the lower part of the page.
Note
- Before you can start the data migration task, DTS performs a precheck. You can start the data migration task only after the task passes the precheck.
- If the task fails to pass the precheck, click View Details next to each failed item. After you analyze the causes based on the check results, troubleshoot the issues. Then, run a precheck again.
- If an alert is triggered for an item during the precheck:
  If an alert item cannot be ignored, click View Details next to the failed item and troubleshoot the issues. Then, run a precheck again.
  If the alert item can be ignored, click Confirm Alert Details. In the View Details dialog box, click Ignore. In the message that appears, click OK. Then, click Precheck Again to run a precheck again. If you ignore the alert item, data inconsistency may occur, and your business may be exposed to potential risks.

Purchase an instance.

Wait until the Success Rate becomes 100%. Then, click Next: Purchase Instance.

On the Purchase Instance page, configure the Instance Class parameter for the data migration instance. The following table describes the parameters.

Section	Parameter	Description
New Instance Class	Resource Group	The resource group to which the data migration instance belongs. Default value: default resource group. For more information, see What is Resource Management?
New Instance Class	Instance Class	DTS provides instance classes that vary in the migration speed. You can select an instance class based on your business scenario. For more information, see Instance classes of data migration instances.

Read and agree to Data Transmission Service (Pay-as-you-go) Service Terms by selecting the check box.
Click Buy and Start. In the message that appears, click OK.
You can view the progress of the task on the Data Migration page.
Note
- If a data migration task cannot be used to migrate incremental data, the task automatically stops. The Completed is displayed in the Status section.
- If a data migration task can be used to migrate incremental data, the task does not automatically stop. The incremental data migration task never stops or completes. The Running is displayed in the Status section.