Migrate an ApsaraDB RDS for MySQL instance that uses X-Engine to a PolarDB for MySQL cluster using the logical migration method. Migration itself is free — you pay only for the destination PolarDB for MySQL cluster.
Prerequisites
Before you begin, make sure that:
-
This migration solution uses the logical migration method. The source ApsaraDB RDS for MySQL instance can be of any version.
-
If the source instance has a trigger, delete the trigger, then click Continue to proceed. Alternatively, click Cancel and manually create a data synchronization task in the Data Transmission Service (DTS) console. For more information, see Configure a data synchronization task for a source database that contains a trigger.
-
If Database Proxy (Safe Mode) is enabled on the source instance, either create a privileged account or switch the network connection mode to high-performance mode. For more information, see Create an account and Switch the network connection mode.
Limitations
| Limitation | Details |
|---|---|
| MySQL version | You can only migrate to the same or a later MySQL version. For example, migrating an ApsaraDB RDS for MySQL 5.7 instance to a PolarDB for MySQL 5.6 cluster, or an ApsaraDB RDS for MySQL 8.0.2 instance to a PolarDB for MySQL 8.0.1 cluster, is not supported. |
| Cross-region migration | Not supported. |
| IPv6 | IPv6 addresses are not supported in switchover with endpoints. |
| Parameter changes | You cannot change parameters on the source instance during migration. |
| Migratable object types | Only five types can be migrated: databases, tables, views, stored procedures, and functions. |
| Table sync limit | A single data synchronization task supports up to 1,000 tables. For more than 1,000 tables, run multiple tasks in batches or sync the entire database instead. |
| Primary key requirement | Tables to be synchronized must have a PRIMARY KEY or UNIQUE constraint with all unique fields. Without this, the destination database may contain duplicate records. |
| Binary logging | Binary logging must be enabled on the source instance, and binlog_row_image must be set to full. For more information, see Modify instance parameters. |
| Binary log retention | For incremental data synchronization only: retain binary logs for at least 24 hours. For full and incremental data synchronization: retain for at least 7 days. After full synchronization completes, you can reduce the retention period to more than 24 hours. For more information, see Manage binary log files. |
Usage notes
-
SSL consistency: The SSL status must be consistent between the source and destination endpoints.
-
If SSL is enabled on the source instance and you use Switch with Endpoints, SSL must also be enabled on the destination PolarDB cluster.
-
If SSL is disabled on the source instance, disable SSL on the destination PolarDB cluster.
-
-
During full data synchronization, DTS reads from and writes to both the source and destination databases, which may increase the load on both servers.
-
During full data synchronization, concurrent INSERT operations cause table fragmentation, so the tablespace of the destination database will be larger than that of the source database after full data synchronization is complete.
-
Do not manually release DTS tasks when using the logical migration method.
-
During full data synchronization, the destination PolarDB cluster is in the Creating state.
Billing
Migration is free of charge. You are only billed for the destination PolarDB for MySQL cluster.
To manage cluster costs, choose whether to enable the hot standby storage cluster feature and select an appropriate storage type when creating the cluster.
Migrate data
For the general migration procedure, see Procedure. The following X-Engine-specific notes apply at each step.
Step 1: Migrate data from the source instance
When creating the destination PolarDB for MySQL cluster, note the following:
-
Only PolarDB for MySQL Enterprise Edition supports both InnoDB and X-Engine. Set Database Edition to Enterprise Edition and Storage Engine to InnoDB & X-Engine, then configure X-Engine Memory Usage. See Step 1: Migrate data from the source ApsaraDB RDS for MySQL instance.
-
Set the billing method to Pay-as-you-go. Pay-as-you-go clusters are not billed during data migration.
Step 2: Switch over services
After you start the migration, verify that tables created in the destination PolarDB cluster use X-Engine. If InnoDB is used instead, submit a ticket.
During the switchover and before the migration is complete, data is reversely migrated from the PolarDB cluster back to the source ApsaraDB RDS for MySQL instance. X-Engine is required for table creation in both directions during this phase.
After the switchover, the default storage engine in the destination PolarDB cluster changes to InnoDB. To create tables that use X-Engine, specify engine=xengine in your DDL statement. For example:
CREATE TABLE my_table (id INT PRIMARY KEY, name VARCHAR(100)) engine=xengine;To make X-Engine the default engine for all new tables, set the default_storage_engine parameter to xengine in the PolarDB console.
After you change default_storage_engine, restart all nodes in the cluster for the change to take effect. Confirm that this restart will not affect your services before proceeding.
For more information, see Step 2: Switch over services.
Step 3: Complete the migration
After migration is complete, InnoDB remains the default storage engine. Use engine=xengine in DDL statements or set default_storage_engine to xengine to use X-Engine.
For more information, see Step 3: Complete the migration.