Checking Database Parameters
1. Checking Configuration Consistency for the lc_monetary Parameter
| Reason for Failure | Suggestion |
|---|---|
| The configuration of the lc_monetary parameter for the source database is inconsistent with that for the destination database. | Modify the configuration of the lc_monetary parameter for the destination database and keep it consistent with that for the source database. |
2. Checking the Configuration of the hot_standby_feedback Parameter
| Reason for Failure | Suggestion |
|---|---|
| The source database is a standby database, and the hot_standby_feedback parameter of the source database is set to off. | Before full data synchronization starts, set the hot_standby_feedback parameter of the source database to on. After full data synchronization ends, change the parameter value back to off. |
3. Checking Whether the wal_level Parameter of the Source Database is Set to logical
| Reason for Failure | Suggestion |
|---|---|
| Incremental Data Migration is selected for the task, and the value of the wal_level parameter of the source database is not logical. | Set the wal_level parameter of the source database to logical. To change the parameter value for a self-managed database, you can use one of the following methods: (1) Use a superuser account to run the alter system set wal_level = logical command on the source database, and then restart the database to apply the setting. (2) Modify the postgresql.conf file by setting the wal_level parameter to logical, and then restart the database to apply the modification. |
4. Checking the max_replication_slots Parameter of the Source Database
| Reason for Failure | Suggestion |
|---|---|
| Incremental Data Migration is selected for the task, and the value of the max_replication_slots parameter of the source database is less than or equal to the number of currently used replication slots. | Change the value of the max_replication_slots parameter to a value greater than the number of currently used replication slots, and then restart the database. Run the following command to query the number of currently used replication slots: Select count(1) from pg_replication_slots; |
5. Checking the max_wal_senders Parameter of the Source Database
| Reason for Failure | Suggestion |
|---|---|
| Incremental Data Migration is selected for the task, and the value of the max_wal_senders parameter of the source database is less than or equal to the number of currently used replication slots. | Change the value of the max_wal_senders parameter to a value greater than the number of currently used replication slots, and then restart the database. Run the following command to query the number of currently used replication slots: Select count(1) from pg_replication_slots; |
6. Checking Whether Primary Keys Exist in Tables to Be Migrated
| Reason for Failure | Suggestion |
|---|---|
| Incremental Data Migration is selected for the task, and the tables to be migrated contain a table that does not have a primary key. | (1) Remove the table that does not have a primary key from the objects to be migrated. (2) Configure a primary key for the table. |
7. Checking the Primary/Standby Status of the Source Database Instance
| Reason for Failure | Suggestion |
|---|---|
| Incremental Data Migration is selected for the task, and the source database instance is not the primary instance. | Select the primary database instance in the cluster as the data source, and then perform the synchronization task. |
Checking User Permissions on Databases
1. Checking User Permissions on the Source Database
| Reason for Failure | Suggestion |
|---|---|
| The account of the source database does not have the USAGE permission on the schema to be migrated. | Connect to the source PostgreSQL database by using a superuser account or an account that is granted the required permissions, and then run the following command to grant the USAGE permission on the schema to the account of the source database: GRANT USAGE ON SCHEMA <schema_name> TO |
| The account of the source database does not have the SELECT permission on the table to be migrated. | Connect to the source PostgreSQL database by using a superuser account or an account that is granted the required permissions, and then run the following command to grant the SELECT permission on the table to the account of the source database: GRANT SELECT ON TABLE <table_name> TO |
| The account of the source database does not have the SELECT permission on the sequence to be migrated. | Connect to the source PostgreSQL database by using a superuser account or an account that is granted the required permissions, and then run the following command to grant the SELECT permission on the sequence to the account of the source database: GRANT SELECT ON SEQUENCE <sequence_name> TO |
| The account of the source database does not have the SELECT permission on the system table pg_catalog.pg_authid. | Connect to the source PostgreSQL database by using a superuser account or an account that is granted the required permissions, and then run the following command to grant the SELECT permission on the system table pg_catalog.pg_authid to the account of the source database: GRANT SELECT ON pg_catalog.pg_authid TO |
2. Checking User Permissions on a Destination Database
| Reason for Failure | Suggestion |
|---|---|
| The account of the destination database does not have the permission to create a schema in the current database. | Connect to the destination PostgreSQL database by using a superuser account or an account that is granted the required permissions, and then run the following command: GRANT CREATE, TEMPORARY, CONNECT ON DATABASE <database_name> TO |
Checking Database Versions
1. Checking PostgreSQL Versions
| Reason for Failure | Suggestion |
|---|---|
| The version of the source database is invalid. The major version cannot be earlier than 9.4. |
The version of the destination database is invalid. The major version cannot be earlier than 9.5.
The major version of the source database is later than the major version of the destination database. | Currently, the PostgreSQL versions supported by DTS for source databases are 9.4, 9.5, 9.6, 10, 11, and 12, and the PostgreSQL versions supported for destination databases are 9.5, 9.6, 10, 11, and 12. Make sure that the PostgreSQL versions of the source and destination databases are within the valid range and that the PostgreSQL version of the destination database is not earlier than that of the source database. |
Checking Network Conditions
1. Checking Source Database Connectivity
| Reason for Failure | Suggestion |
|---|---|
| The account or password of the source database is incorrect. | Enter the correct database account and password, and then re-perform the precheck. |
| The network or server where the source database is deployed is configured with a firewall. | Check whether the firewall of the network where the database is deployed blocks the CIDR block or IP address of your DTS instance. If yes, disable the firewall or add the CIDR block or IP address of the DTS instance to the IP address trustlist of the firewall. |
| The permissions of the migration account to log in to the source database are insufficient. | Log in to the source database, and grant the migration account the relevant remote access permissions. |
| A network connectivity issue occurred. | Contact the administrator of the machine where the database runs and the administrator of the machine where your DTS instance is deployed for troubleshooting. |
2. Checking Destination Database Connectivity
| Reason for Failure | Suggestion |
|---|---|
| The account or password of the destination database is incorrect. | Enter the correct database account and password, and then re-perform the precheck. |
| The network or server where the destination database is deployed is configured with a firewall. | Check whether the firewall of the network where the database is deployed blocks the CIDR block or IP address of your DTS instance. If yes, disable the firewall or add the CIDR block or IP address of the DTS instance to the IP address trustlist of the firewall. |
| The permissions of the migration account to log in to the destination database are insufficient. | Log in to the destination database, and grant the migration account the relevant remote access permissions. |
| A network connectivity issue occurred. | Contact the administrator of the machine where the database runs and the administrator of the machine where your DTS instance is deployed for troubleshooting. |
Checking Database Objects
1. Checking Schema Names and Table Names in Source Databases for Invalidity
| Reason for Failure | Suggestion |
|---|---|
| The names of objects to be migrated contain invalid characters. | (1) Rename the objects whose names contain invalid characters. (2) Remove the objects whose names contain invalid characters from the objects to be migrated. |
2. Checking Object Name Conflicts
| Reason for Failure | Suggestion |
|---|---|
| The destination database contains objects that have name conflicts with the objects to be migrated, which means that their names are the same. | (1) Remove objects with name conflicts from the objects to be migrated. (2) Create mappings for objects with name conflicts. (3) Delete objects with name conflicts from the destination database. |
3. Checking Integrity Constraints
| Reason for Failure | Suggestion |
|---|---|
| The parent table on which the child table to be migrated depends is not selected as an object to be migrated. | (1) Add the corresponding parent table to the objects to be migrated. (2) Remove the corresponding child table from the objects to be migrated. (3) Delete the relevant foreign key dependency. |
4. Checking Plug-in Compatibility
| Reason for Failure | Suggestion |
|---|---|
| The source database is installed with an extended plug-in that does not exist in the destination database. | |
| The version of the plug-in in the source database is later than that in the destination database. | Create the corresponding plug-in in the destination database. |
5. Checking the Installation of the Logical Decoder Plug-in
| Reason for Failure | Suggestion |
|---|---|
| Incremental Data Migration is selected for the task, and the source database is not installed with the logical decoder plug-in decoderbufs. | Install the logical decoder plug-in decoderbufs in the source database. |
6. Checking Whether Primary Keys Exist in Tables to Be Migrated
| Reason for Failure | Suggestion |
|---|---|
| Incremental Data Migration is selected for the task, and the tables to be migrated contain a table that does not have a primary key. | (1) Remove the table that does not have a primary key from the objects to be migrated. (2) Configure a primary key for the table. |
7. Checking the Existence of Unlogged Tables
| Reason for Failure | Suggestion |
|---|---|
| Incremental Data Migration is selected for the task, and the currently selected objects to be migrated contain unlogged tables. | Confirm whether incremental data synchronization is required for these tables. If yes, remove the UNLOGGED property from these tables by running the following command: ALTER TABLE SET LOGGED; |
8. Checking Metadata for DDL Synchronization
| Reason for Failure | Suggestion |
|---|---|
| The metadata tables required for DDL synchronization are not selected. The metadata tables required for DDL synchronization do not exit. The function required for DDL synchronization does not exist. The event trigger required for DDL synchronization does not exist. | If you want to synchronize DDL statements, follow the guidelines to create the following required metadata objects in the source database: dts_ddl_info, dts_capture_ddl, and dts_ddl_event. Select the dts_ddl_info object as an object to be synchronized, and then re-perform the precheck. |