1.1.1 Product Consulting
1.1.1.1 What are the application scenarios of the database migration tool?
When you need to migrate database data of other cloud service providers to eSurfing Cloud, you can use the database migration tool to orderly, securely, conveniently and easily migrate data to eSurfing Cloud, in part or in full, while ensuring the availability, security and continuity of applications on the cloud.
1.1.1.2 Does the database migration tool support migration from Alibaba Cloud, eSurfing Cloud, and other cloud platforms to eSurfing Cloud?
Yes.
The database migration tool can migrate the database of mainstream cloud service providers in the market to eSurfing Cloud, such as Alibaba Cloud, eSurfing Cloud, and Tencent Cloud.
1.1.1.3 Does the database migration tool support the migration of data on eSurfing Cloud to other cloud service providers or on-premises servers?
No.
For the ZOS migration tool, you can only select eSurfing Cloud as the migration target and thus you cannot migrate data on eSurfing Cloud to an on-premises server or other cloud service providers.
1.1.1.4 Can I ask eSurfing Cloud engineers to help me with the migration when I use the database migration tool?
eSurfing Cloud engineers are not directly involved in your business migration. You can conduct your migration by referring to the Help Center.
If your issues are not mentioned in the Help Center, you can submit your issues on the page, and our engineers will provide supplementary content later.
If you need professional migration solutions and customized technical support, you can order our migration services to help you smoothly migrate applications, shorten the downtime, reduce the impact of cloud migration on your business continuity, relieve your concerns about cloud migration, and focus on business development.
1.1.1.5 How to migrate multiple databases on the source database to one eSurfing Cloud database?
Assuming there are two databases on the source database, you can create two migration tasks:
Create migration task 1: Database A on the source database > Database A in eSurfing Cloud
Create migration task 2: Database B on the source database > Database A in eSurfing Cloud
If an object with the same name exists, use the table name mapping function to modify the object name as required.
1.1.1.6 Does the migration have any impact on the data on the source server?
The migration has no impact on the data on the source server.
Data on the source server is not modified during migration.
Objects on the source server are not locked during migration.
Data on the source server will not be deleted after the migration is complete.
1.1.1.7 How can I ensure data consistency using the database migration tool If data is written to the database all the time?
This problem can be handled in the following two aspects:
1. When incremental data migration is enabled, the database migration tool automatically captures incremental data changes and migrates them to the target database.
2. If incremental data migration is not enabled, you can configure an auditing repair task to ensure data consistency after data migration when data changes no longer occur on the source database.
1.1.1.8 What are the applicable scenarios of database migration tasks?
Apply to migrate database data with volume of a single database less than 1 TB or with less than 1000 tables. You can create a data migration task to quickly migrate database data. For more information see Create a Migration Task.
1.1.1.9 Does the migration affect existing data in the tables on the target server?
The impact of the database migration tool on existing data in the tables on the target server depends on whether tables on the target server have the same name as the source server.
If no table with the same name exists, the database migration tool has no impact on existing data in the tables on the target server.
If tables with the same names exist, the migration fails in the following scenarios:
A table with the same name exists, and "Allow users to create a table" is not selected.
A table with the same name exists and "Allow users to create a table" is selected. The table contains a primary key, and the primary key has a duplicate value with that on the source server.
If tables with the same names exist, data will be inserted into the tables on the target server in the following scenarios:
A table with the same name exists and "Allow users to create a table" is selected. The table contains a primary key, and the primary key has no duplicate value with that on the source server.
A table with the same name exists, "Allow users to create a table" is selected, and the table contains no primary key.
For data integrity, and because data transfer is irreversible, you are advised not to migrate resources to tables with data on the target server.
1.1.1.10 What are the possible causes for data inconsistency between the source and target servers after database migration?
Possible causes for data inconsistency are as follows:
1. Before a task is started, the data on the target server is not cleared, and there is stock data.
2. When you configure a task, only the full data migration mode is selected and the incremental data migration mode is not selected, and the data on the source server changes during migration.
3. The target database has other data written in addition to the database migration tool.
4. There is a delay in incremental data migration, and incremental data cannot be fully written to the target database.
1.1.1.11 Can data inconsistency occur if I configure a full data migration task before configuring an incremental data migration task?
Data inconsistencies may occur. If only incremental data migration is configured, data migration starts after the task is started. Before the task is started, the incremental data generated in the source database will not be synchronized to the target database. If you need to perform migration without service interruption, you are advised to select both full data migration and incremental data migration as the migration type when configuring a task.
1.1.1.12 How do I know if incremental migration can be stopped?
You can determine whether incremental migration can be stopped in the following steps:
1. First interrupt the service.
2. On the source database, the application system is deemed stopped if no SQL is executed in any new session within 1-5 minutes.
3. You can manually stop incremental migration after the number of incremental migrations does not change and remains stable for a period of time.
1.1.2
1.1.2.1 What are the compatibility lists?
For more information, see the Compatibility List.
What are the migration restrictions?
For more information, see Migration Restrictions and Limitations, and prerequisites and requirements for task configuration.
1.1.2.2 Why cannot a system library be synchronized or migrated?
Since migrating/synchronizing data from the system library to the target library may affect the availability of the database instances, the system library of the database cannot be used as the source or target.
1.1.2.3 Why cannot a higher version be migrated to a lower version?
We recommend that you keep the source and target library versions the same, or migrate from an earlier version to a later version to ensure compatibility. Database compatibility problems may occur if a later version migrates to an earlier version.
1.1.2.4 What are the important disclaimers for the database migration tool?
For more information, see Disclaimer.
1.1.3
1.1.3.1 How can I view the progress of a migration task?
In general, the reference value for the migration speed of the database migration tool is 200-240 GB an hour. The migration speed depends on the number and size of objects on the source server and transmission distance over Internet. We recommend that you create a real data migration task to test the actual migration speed.
1.1.3.2 Why is migration sometimes slow?
There are many factors affecting the migration speed, such as the size of the migrated tables, the number of ongoing tables, and the network environment. The reasons for slow migration without taking into account the network environment can be as follows:
A large number of small tables
Because the maximum number of concurrent migrations per migration task is fixed, the number of tables that can be migrated at a time is limited. Tables are enumerated before migration starts. Compared with migrating large tables, migrating the same amount of data consumes more time to enumerate tables.
Solution: Split the tables on the source server to be migrated into multiple migration tasks for concurrent migration to increase the migration speed.
Migrate a small number of large objects.
If there are few objects to be migrated (less than 10) and the size is large, the migration concurrency is low. Therefore, the migration speed becomes low.
In this case, there is nothing to do but wait patiently. The migration speed cannot be increased.
1.1.3.3 How long will a migration task take?
You can estimate the migration duration before migration starts using the following formula: Migration duration = Total data volume/Bandwidth size/8*1.25. For more information about duration estimation, see Evaluate Migration Duration and Test Transfer Speed.
1.1.3.4 What determines the migration bandwidth?
The minimum bandwidth among the following three bandwidth specifications shall be used:
· Egress bandwidth of data source.
· Ingress bandwidth on the target server.
· Bandwidth limit on the data migration platform.
1.1.3.5 How do I know if a migration task gets stuck?
· Check whether the current progress of the database migration tool (number of records, total elapsed time) is normal.
· Check the migration log on the source server. If the log is not refreshed for an extended period of time, the task may be abnormal.
1.1.3.6 Why is the migration speed sometimes much lower than the bandwidth size?
The reasons for this phenomenon are generally but not limited to the following:
· A large table contains many rows, but the average row size is small
· A large number of small tables
· Disk I/O is limited on the source database or target database
1.1.4 store from Abnormal Conditions
1.1.4.1 What should I do if "function uuid_generate_v4() does not exist" is reported in a migration task?
This is because the uuid-ossp plug-in is not installed on the target PostgreSQL database. Perform the following operations to restart the migration task.
You must install the uuid-ossp plug-in on the target PostgreSQL database. Download URL: http://www.ossp.org/pkg/lib/uuid/. After installing the plug-in, execute the create extension "uuid-ossp" statement
under the SCHEMA of the target database.
1.1.4.2 What should I do if "invalid input syntax for type bigint XXX" is reported in a migration task?
This is because no accuracy is configured for table fields in the source database. Perform the following operations to restart the migration task.
For tables that do not have accuracy settings, configure the accuracy settings according to the actual data condition.
1.1.4.3 What should I do if "ORA-12547: TNS:lost contact" is reported in a migration task?
This is because the node is not added to the database trustlist. Perform the following operations to restart the migration task.
Add the service node address to the database trustlist.
1.1.4.4 How to create a migration task again after the migration is complete?
You can click Retry after cleaning up the target database.
1.1.4.5 What should I do if the connection test fails when I create a migration task?
Check whether the database allows Internet access.
If Internet access is not allowed, enable Internet access.
If Internet access is allowed, check whether the node address is included in the database trustlist. If not, add the node address to the database trustlist.
1.1.4.6 What should I do if "Packet for query is too large (x>y). You can change this value on the server by setting the 'max_allowed_packet' variable" is reported in a migration task?
The max_allowed_packet variable in MySQL is lower than the size submitted in the cloud migration batch processing.
Because the column is set to the default value, a default value is generated after filtering.
Procedure:
1. Run the "set global max_allowed_packet=z" in MySQL. The value of z must be higher than the value of x in the error message.
1.1.4.7 What should I do if "Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs." is reported in a migration task?
According to MySQL, the length of all fields in a table cannot exceed 65535.
Procedure:
Replace the type of an excessively long field in the source database with Text or blob.
1.1.4.8 What should I do if "relation "XXX" does not exist" is reported in a migration task?
The table-dependent objects do not exist.
Procedure:
Manually migrate table-dependent objects to the target database, and then restart the migration task.
1.1.4.9 What should I do if "type XXX does not exist" is reported in a migration task?
The table-dependent data types do not exist.
Procedure:
Manually migrate the table-dependent data types to the target database, and then perform the migration again. Heterogeneous databases may not be built and will not be migrated.
1.1.4.10 What should I do if the migration/subscription/synchronization task is slow or gets stuck?
The steps are as follows:
(1) Evaluate and obtain the amount of data on the source database to estimate the migration time, and check whether the current performance meets the expectations.
(2) Check whether the memory and CPU of the server where the node is located are full. If so, you are advised to execute the tasks in batches in different periods to avoid resource shortage.
(3) Check whether the memory, CPU, I/O, and disk of the server where the source and target databases reside are full. If so, check the resource usage and reduce the resource utilization before restarting the migration.
(4) Check whether the network connectivity and bandwidth are limited, and upgrade the bandwidth if conditions permit.
1.1.4.11 Why are there more migration records than expected?
After the migration task starts, new data is written to the source database.
Solution:
(1) Do not change the data on the source database after the migration task starts if only full data migration is selected for the migration task.
(2) Select both full data migration and incremental data migration to synchronize incremental data.
1.1.4.12 Why do columns filtered in a migration task have a value after migration?
Because the column is set to the default value, a default value is generated after filtering.
Solution: Remove the default value configurations for the columns.