Type | Description |
Source database limitations | The server that hosts the source database must have sufficient outbound bandwidth. Insufficient bandwidth can affect the migration speed. Each table to be migrated must have a primary key or a unique constraint. All fields in the key or constraint must be unique to prevent duplicate data in the destination database. If you migrate objects at the table level and need to perform edits such as column name mapping, a single migration task supports a maximum of 1,000 tables. If you exceed this limit, an error is reported when you submit the task. In this case, you can split the tables into multiple tasks or configure a task to migrate the entire database. For incremental migration, you must configure write-ahead logging (WAL): Operational limitations on the source database: During the schema migration and full data migration phases, do not perform any DDL operations that alter the schema of databases or tables. Otherwise, the migration task will fail. If you perform only full data migration, do not write new data to the source instance to avoid data inconsistency. To maintain real-time data consistency, we recommend selecting schema migration, full data migration, and incremental data migration. To ensure the migration task runs smoothly and to prevent logical subscription interruptions caused by a primary/secondary switchover, the source PolarDB for PostgreSQL(Compatible with Oracle) cluster must support logical replication slot failover and have it enabled.
Note If the source PolarDB for PostgreSQL(Compatible with Oracle) cluster does not support logical replication slot failover (for example, if the cluster's database engine is Oracle syntax compatibility 2.0), a high-availability (HA) switchover on the source database can cause the migration instance to fail and become unrecoverable. Due to the limits of logical replication in the source database, if a single piece of data to be migrated exceeds 256 MB after an incremental change, the migration instance may fail and cannot be recovered. You must reconfigure the migration instance.
If long-running transactions exist in the source database during an incremental migration, write-ahead logging (WAL) records generated before these transactions commit cannot be cleared. This can cause WAL files to accumulate and exhaust the disk space of the source database.
|
Other limitations | A single data migration task can migrate only one database. To migrate multiple databases, you must configure a separate migration task for each one. DTS does not support the migration of tables created by the TimescaleDB extension, tables with cross-schema inheritance, or tables with unique indexes based on expressions. These schemas will not be visible in the console when you configure the task. If a table to be migrated contains a SERIAL column, the source database automatically creates a sequence for that column. Therefore, when you configure the Source Objects, if you select Schema Migration for Migration Types, select Sequence or migrate the entire schema. Otherwise, the migration instance may fail. If the migration instance performs incremental data migration, you must run the ALTER TABLE schema.table REPLICA IDENTITY FULL; command on the tables to be migrated in the source database before you write data to them. This ensures data consistency. This requirement applies in the following two scenarios. During the execution of this command, do not perform table lock operations to avoid deadlocks. If you skip the related check in the precheck, DTS automatically runs this command during the instance initialization. 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.
DTS creates the following temporary tables in the source database to obtain information such as DDL statements for incremental data, the structure of incremental tables, and heartbeats. Do not delete these temporary tables during the migration, as this will cause the task to fail. The 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.
To ensure the accuracy of latency metrics for incremental data migration, DTS creates a heartbeat table named dts_postgres_heartbeat in the source database. During incremental data migration, DTS creates a replication slot with the dts_sync_ prefix in the source database to replicate data. Using this replication slot, DTS can obtain incremental logs from the source database within the last 15 minutes. When the data migration fails or the migration instance is released, DTS attempts to automatically clear this replication slot.
Note If you change the password of the source database account used by the task or delete the DTS IP address whitelist from the source database during data migration, the replication slot cannot be automatically cleared. In this case, you must manually clear the replication slot in the source database to prevent it from accumulating and occupying disk space, which can make the source database unavailable. If a failover occurs in the source database, you must log on to the secondary database to manually clear the slot.
Before you start the migration, evaluate the performance of both the source and destination databases. We recommend that you run the migration during off-peak hours. During full data migration, DTS consumes read and write resources on both databases, which can increase their load. Concurrent INSERT operations during full data migration can cause table fragmentation, which may result in the destination database using more storage space than the source instance. Verify that the migration precision for columns of the FLOAT or DOUBLE data types meets your business requirements. DTS uses the ROUND(COLUMN,PRECISION) function to read values from these columns. If a precision is not explicitly defined, DTS uses a precision of 38 for FLOAT and 308 for DOUBLE. DTS attempts to resume a failed migration task for up to seven days. Before you switch business workloads to the destination instance, you must end or release the task, or revoke the write permissions of the account that DTS uses to access the destination instance by using the revoke command. This prevents an automatically resumed task from overwriting data in the destination instance. DTS validation checks data content but does not support metadata validation for objects such as sequences. You must validate these objects manually. After you switch your business to the destination instance, new sequences do not start incrementing from the maximum value of the source sequences. You must update the sequence values in the destination database before the switchover. For more information, see Update the sequence values in the destination database. For a full or incremental migration task, if the tables to be migrated in the source database contain foreign keys, triggers, or event triggers, DTS temporarily sets the session_replication_role parameter to replica at the session level if the destination database account is a privileged account or has superuser permissions. If the destination database account does not have these permissions, you must manually set the session_replication_role parameter to replica in the destination database. During this period (when session_replication_role is replica), if cascade update or delete operations occur in the source database, data inconsistency may occur. After the DTS migration task is released, you can change the session_replication_role parameter back to origin. -
If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.
Note
Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.
When migrating partitioned tables, you must include the parent table and all its child partitions as migration objects to prevent data inconsistency.
Important In PolarDB for PostgreSQL(Compatible with Oracle), the parent table of a partitioned table does not store data directly. Data is stored in the child partitions. The migration task must include the parent table and all its child partitions to prevent data loss and inconsistency between the source and destination databases. Migration of partitioned tables or inherited tables (parent and child tables) that are distributed across different databases is not supported. Ensure that the partitioned tables and all their partitions, as well as parent tables and all their child tables, are in the same database.
|