This topic describes how to migrate incremental data from a user-created PostgreSQL database to an ApsaraDB RDS for PostgreSQL instance by using Data Transmission Service (DTS). DTS supports schema migration, full data migration, and incremental data migration. When you migrate data from a user-created PostgreSQL database to Alibaba Cloud, you can select all of the supported migration types to ensure service continuity.
- The version of the user-created PostgreSQL database is 10.1 to 12.
- An ApsaraDB RDS for PostgreSQL instance is created. For more information, see Create an RDS for PostgreSQL instance.
Note Ensure that the database version of the ApsaraDB RDS for PostgreSQL instance is the same as the version of the user-created PostgreSQL database.
- The available storage space of the ApsaraDB RDS for PostgreSQL instance is larger than the total size of the data in the user-created PostgreSQL database.
- DTS uses read and write resources of the source and destination databases during full data migration. This may increase the database load. If the database performance is unfavorable, the specification is low, or the data volume is large, database services may become unavailable. For example, DTS occupies a large amount of read and write resources in the following cases: a large number of slow SQL queries are performed on the source database, the tables have no primary keys, or a deadlock occurs in the destination database. Before you migrate data, evaluate the performance of the source and destination databases. We recommend that you migrate data during off-peak hours. For example, you can migrate data when the CPU usage of the source and destination databases is less than 30%.
- The source database must have PRIMARY KEY or UNIQUE constraints and all fields must be unique. Otherwise, duplicate data may exist in the destination database.
- To ensure that the delay time of incremental data migration is accurate, DTS adds a heartbeat table named dts_postgres_heartbeat to the source database.
- During incremental data migration, DTS creates a replication slot for the source database.
The replication slot is prefixed with
dts_sync_. DTS automatically clears historical replication slots every 90 minutes to prevent them from occupying disk space.Note If a migration task is released or fails, DTS automatically clears the replication slot. After a switchover between primary and secondary ApsaraDB RDS for PostgreSQL databases, you must log on to the secondary database to manually clear the replication slot.
- DTS automatically resumes a failed data migration task. Before you switch your workloads to the destination instance, stop or release the data migration task. Otherwise, the data in the source database will overwrite the data in the destination instance after the task is resumed.
- A single data migration task can migrate data from only one database. To migrate data from multiple databases, you must create a data migration task for each database.
- During incremental data migration, only data manipulation language (DML) operations, such as INSERT, UPDATE, DELETE, and UPDATE operations, can be migrated.
|Migration type||Instance configurations||Internet traffic|
|Schema migration and full data migration||Free of charge.||Charged only when data is migrated from Alibaba Cloud over the Internet. For more information, see Pricing.|
|Incremental data migration||Charged. For more information, see Pricing.|
Permissions required for database accounts
|Database||Schema migration||Full data migration||Incremental data migration|
|User-created PostgreSQL database||The usage permission on pg_catalog||The SELECT permission on the objects to be migrated||The superuser permission|
|ApsaraDB RDS for PostgreSQL instance||The create and usage permissions on the objects to be migrated||The owner permission on schemas||The owner permission on schemas|
For more information about how to create and authorize a database account, see the following topics:
Data migration process
To avoid data migration failures caused by dependencies between objects, DTS migrates the schemas and data of the source PostgreSQL database in the following order:
|Data migration process||Description|
|1. Schema migration||DTS migrates the schemas of tables, views, sequences, functions, user-defined types,
rules, domains, operations, and aggregates to the destination database.
Note Functions that are written in the C programming language cannot be migrated.
|2. Full data migration||DTS migrates historical data of the required objects to the destination database.|
|3. Schema migration||DTS migrates the schemas of triggers and foreign keys to the destination database.|
|4. Incremental data migration||DTS migrates incremental data of the required objects to the destination database.
Note Incremental data migration does not support the bit data type.
- Log on to the server to which the user-created PostgreSQL database belongs.
- Set the value of the wal_level parameter in the
postgresql.confconfiguration file to
logical.Note Skip this step if you do not need to perform incremental data migration.
- Add the CIDR blocks of DTS servers to the pg_hba.conf configuration file of the user-created PostgreSQL database. You only need to add the CIDR blocks of DTS servers that are located in the same region as the destination database. For more information, see Add the CIDR blocks of DTS servers to the security settings of on-premises databases.
- Log on to the DTS console.
- In the left-side navigation pane, click Data Migration.
- At the top of Migration Tasks the page, select the region where the destination cluster resides.
- In the upper-right corner of the page, click Create Migration Task.
- Configure the source and destination databases for the data migration task.
Section Parameter Description N/A Task Name DTS automatically generates a task name. We recommend that you specify an informative name for easy identification. You do not need to use a unique task name. Source Database Instance Type Select an instance type based on where the source database is deployed. The procedure in this topic uses User-Created Database with Public IP Address as an example.Note If you select other instance types, you must prepare the environments that are required for the source database. For more information, see Preparation overview. Instance Region If the instance type is set to User-Created Database with Public IP Address, you do not need to specify the instance region. Database Type Select PostgreSQL. Hostname or IP Address Enter the endpoint that is used to connect to the user-created PostgreSQL database. In this example, enter the public IP address. Port Number Enter the service port number of the user-created PostgreSQL database. The port is accessible over the Internet. Database Name Enter the name of the user-created PostgreSQL database. Database Account Enter the account of the user-created PostgreSQL database. Database Password Enter the password for the source database account.Note After you specify the source database parameters, click Test Connectivity next to Database Password to verify whether the specified parameters are valid. If the specified parameters are valid, the Passed message appears. If the Failed message appears, click Check next to Failed. Modify the source database parameters based on the check results. Destination Database Instance Type Select RDS Instance. Instance Region Select the region where the destination RDS instance resides. RDS Instance ID Select the ID of the destination RDS instance. Database Name Enter the database name of the destination RDS instance. The name can be different from the name of the user-created PostgreSQL database.Note Before you configure the data migration task, create a database in the ApsaraDB RDS for PostgreSQL instance. For more information, see Create a database. Database Account Enter the database account of the destination RDS instance. Database Password Enter the password for the destination database account.Note After you specify the destination database parameters, click Test Connectivity next to Database Password to verify whether the parameters are valid. If the specified parameters are valid, the Passed message appears. If the Failed message appears, click Check next to Failed. Modify the destination database parameters based on the check results.
- In the lower-right corner of the page, click Set Whitelist and Next.Note The CIDR blocks of DTS servers are automatically added to the whitelist of the destination ApsaraDB RDS for PostgreSQL instance. This ensures that DTS servers can connect to the destination ApsaraDB RDS for PostgreSQL instance.
- Select the migration types and objects to be migrated.
Parameter Description Migration Types
Note If Incremental Data Migration is not selected, do not write data into the source database during full data migration. This ensures data consistency between the source and destination databases.
- To perform only full data migration, select Schema Migration and Full Data Migration.
- To migrate data with minimal downtime, select Schema Migration, Full Data Migration, and Incremental Data Migration. In this example, all of the three migration types are selected.
Select objects from the Available section and click the icon to move the objects to the Selected section.Note
- You can select columns, tables, or Schemas as the objects to be migrated. If you select
a Schema as an object to be migrated in a data migration task, new tables that are
created after the task is started can also be migrated. However, you must run the
following statement on the new tables before they can be migrated:
ALTER TABLE schema.table REPLICA IDENTITY FULL;
You must replace the schema and table in the preceding sample statement with the actual schema name and table name.
- After an object is migrated to the destination RDS instance, the name of the object remains the same as that in the user-created PostgreSQL database. You can change the names of the objects that are migrated to the destination RDS instance by using the object name mapping feature. For more information about how to use this feature, see Object name mapping.
- If you use the object name mapping feature on an object, other objects that are dependent on the object may fail to be migrated.
- Click Precheck on the lower right of the page.
- A precheck is performed for a data migration task. A data migration task can be started only if it passes the precheck.
- If the precheck fails, click icon corresponding to each failed item to view the details. Fix the problems as instructed and run the precheck again.
- After the precheck is passed, click Next.
- On the Confirm Settings dialog box that appears, specify Channel Specification and select the Data Transmission Service (Pay-As-You-Go) Service Terms.
- Click Buy and Start to start the migration task.
Stop the migration task
- Full data migration
Do not manually stop a task during full data migration. Otherwise, the system may fail to migrate all data. Wait until the migration task automatically ends.
- Incremental data migration
The task does not automatically end during incremental data migration. You must manually stop the migration task.
- Wait until the task progress bar shows Incremental Data Migration and The migration task is not delayed. Then, stop writing data to the source database for a few minutes. In some cases, the progress bar shows the delay time of incremental data migration.
- After the status of incremental data migration changes to The migration task is not delayed, manually stop the migration task.