Prerequisites
• Source
– Account permission requirements:
• Query permissions on the MySQL database.
• Query permissions on the database to be migrated.
• Partial global permissions: RELOAD, LOCK TABLES, REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, PROCESS.
• In the case of an entire instance migration, query permissions on all databases are required.
– Other requirements:
• The public network access is enabled, and the external network connection address can be obtained.
• Destination
– Account permission requirements:
• The following global permissions are required: ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE USER, CREATE VIEW, DELETE, DROP, EVENT, EXECUTE, INDEX, INSERT, LOCK TABLES, PROCESS, RELOAD, SELECT, SHOW DATABASES, SHOW VIEW, TRIGGER, UPDATE.
– Other requirements:
• RDS for MySQL is created.
• The EIP is bound.
Constraints and Restrictions
• If the migration object is at the table level, up to 600 tables can be migrated in a single migration task. When the number limit is exceeded, the task will request to report an error after the task is submitted. In this case, it is recommended that you split the tables to be migrated, configure multiple tasks in batches, or configure the task as a database migration.
• It is recommended to enable GTID for the source database. If GTID is disabled on the source database instance, DTS does not support the primary/standby HA switching, because the DTS task will be interrupted due to the non-continuation of the site, which cannot be restored.
• The RDS database associated with the destination database must have the same character set as the source database.
• If row data exists in the destination database, the data with the same primary key in the source database will overwrite the existing data in the destination database during incremental migration through DTS. Therefore, you need to determine whether to clear the data before migration. It is recommended that you empty the destination database before migration.
• The binlog of the MySQL source database must be enabled and use the row-based format.
• If the disk space is sufficient, store the source database binlog as long as possible. The recommended retention period is seven days. Otherwise, DTS may not obtain binlog during incremental migration, causing the task failure. Make sure that you configure the retention period of Binlogs based on the DTS requirements. Otherwise, the issues caused are not covered by the service level agreement (SLA) of DTS.
• The running state of the target instance and the associated RDS instance must be normal. If the associated RDS instance is a primary/standby instance, the replication state must also be normal.
• The RDS instance associated with the destination database must have sufficient disk space. (During full data migration, concurrent INSERT operations cause fragmentation in the tables of the destination database. Therefore, after full migration is complete, the size of the used tablespace of the destination database is larger than that of the source instance. In addition, a large number of Binlogs will be generated, taking up a lot of space).
• If the destination database instance uses columns of the TIMESTAMP or DATETIME type as its sharding key, the seconds precision of the column is removed after the data is migrated from the source database to the destination database.
• As DTS does not migrate USER information, you need to grant read and write permissions to the caller when calling the views, stored procedures, and functions of the destination database.
• During the task start-up and full task migration, it is not recommended to perform DDL operations of deletion type on the source database. Otherwise, the migration task may fail.
• During the migration, do not modify or delete the usernames, passwords, and permissions of the users of the source and destination databases or change the port numbers of the source and destination databases.
• During the migration, do not modify the table structures of the source database to be migrated.
• During an incremental migration of table-level objects, renaming tables is not supported.
• During an incremental migration, restoration operations are not supported for the source database.
• In the incremental migration scenario, data incremental migration of tables without primary keys is not supported due to its poorer performance than that of tables with primary keys, and data consistency cannot be guaranteed.
² Note
For details,see Data Transmission Service (DTS)
Procedure
Log in to the Console.
In the upper left corner of the Console, click
and select Region and Project.
Select Database > Data Transmission Service to go to the DTS console.
Click Data Migration on the left menu bar.
Click the Create Instance button to create a DTS migration instance.
In the Information Configuration column, select Public Network EIP as the network access type, and select any available EIP.
² Note
If you already have an EIP available on eSurfing Cloud, you can use it directly, otherwise, you need to purchase an EIP to realize public network access to the DTS instance.
Select the destination database instance that you want to import.
After filling in the information, click Next > Create Now to start creating the DTS instance.
Return to the DTS Console, wait until the DTS instance is successfully created, find the corresponding instance, and click Instance Configuration.
Fill in the IP address, port number, database account number, and password of the source database (database of another cloud). Fill in the database account number and password of the destination database and click Test Connectivity and Next.
Select the database to be migrated at Source Database Objects, and click the arrow to move to Selected Objects.
Click Next Precheck and wait for the precheck to complete.
² Note
If the pre-check fails, you can modify it according to the prompt, and then perform the pre-check again.
Click Start Migration to start the data migration.
The migration is completed when the DTS instance status is changed from Running to Completed.