You can upgrade an ApsaraDB RDS for MySQL instance that uses X-Engine to a PolarDB for MySQL cluster by using the logical migration method. This topic describes the precautions, prerequisites, procedure, and billing for such migrations.
Prerequisites
This migration solution uses the logical migration method. The source ApsaraDB RDS for MySQL instance can be of any version.
If a trigger is created for the source ApsaraDB RDS for MySQL instance, delete the trigger and then click Continue. Alternatively, you can click Cancel and then manually create a data synchronization task in the 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 for the ApsaraDB RDS for MySQL instance, a privileged account is created or the network connection mode of the ApsaraDB RDS for MySQL instance is switched to high-performance mode. For more information, see Create an account and [Product changes/Feature changes] The network connection mode of an ApsaraDB RDS instance is upgraded.
Limits
You can upgrade an ApsaraDB RDS for MySQL instance only to a PolarDB for MySQL cluster of the same or a later MySQL version, but not to a cluster of an earlier MySQL version. For example, you cannot upgrade an ApsaraDB RDS for MySQL 5.7 instance to a PolarDB for MySQL 5.6 cluster, or upgrade an ApsaraDB RDS for MySQL 8.0.2 instance to a PolarDB for MySQL 8.0.1 cluster.
IPv6 addresses are not supported in switchover with endpoints.
Cross-region data migration is not supported.
You cannot configure parameters of the source ApsaraDB RDS for MySQL instance during data migration.
Only five types of structures can be migrated: databases, tables, views, stored procedures, and functions.
Source ApsaraDB RDS for MySQL instances are subject to the limits listed in the following table.
Item
Description
Limits on the source instance
The tables to be synchronized must have PRIMARY KEY or UNIQUE constraints and all fields must be unique. Otherwise, the destination database may contain duplicate data records.
If you select tables as the objects to be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, up to 1,000 tables can be synchronized in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.
The following requirements for binary logs must be met:
The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify instance parameters. In addition, the binlog_row_image parameter must be set to full. Otherwise, error messages are returned during precheck, and the data synchronization task cannot be started.
For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Otherwise, DTS may fail to obtain the binary logs and the task may fail. In extreme circumstances, data inconsistency or loss may occur. Make sure that you configure the retention period of binary logs in accordance with the preceding requirements. Otherwise, the SLA of DTS does not guarantee service reliability and performance. For more information about binary log files of an ApsaraDB RDS for MySQL instance, see Manage binary log files.
Precautions
Whether SSL is enabled must be consistent on the endpoints of the source ApsaraDB RDS for MySQL instance and the destination PolarDB cluster.
If SSL is enabled on the endpoint of the source ApsaraDB RDS for MySQL instance and you select Switch with Endpoints to switch the endpoints, make sure that SSL is enabled on the endpoint of the PolarDB cluster.
If SSL is disabled on the endpoint of the source ApsaraDB RDS for MySQL instance, make sure that SSL is also disabled on the endpoint of the PolarDB cluster.
During initial full data synchronization by using the logical migration method, DTS uses read and write resources of the source and destination databases. This may increase the loads on the database servers.
During full data synchronization by using the logical migration method, concurrent INSERT operations cause fragmentation in the tables of the destination database. After full data synchronization is complete, the tablespace of the destination database is larger than that of the source database.
When the logical migration method is used, do not manually release DTS tasks.
Full data synchronization takes some time. The time consumed depends on the amount of data. During this period, the destination PolarDB cluster is in the Creating state.
Billing
Migration fees
You are not charged for data migrations during the upgrade. You are charged only for the destination PolarDB for MySQL cluster.
You can manage the costs of the destination PolarDB for MySQL cluster by specifying whether to enable the hot standby storage cluster feature and by selecting appropriate storage types.
Procedure
For more information about how to upgrade an ApsaraDB RDS for MySQL instance that uses X-Engine to a PolarDB for MySQL cluster, see Procedure. For an ApsaraDB RDS for MySQL instance that uses X-Engine, take note of the following points:
In Step 1: Migrate data from the source ApsaraDB RDS for MySQL instance:
Only PolarDB for MySQL Enterprise Edition supports InnoDB and X-Engine. When you create a PolarDB for MySQL cluster, set Database Edition to Enterprise Edition and Storage Engine to InnoDB & X-Engine, and then configure X-Engine Memory Usage.
We recommend that you set the billing method of the PolarDB for MySQL cluster to Pay-as-you-go. Pay-as-you-go clusters are not billed for data migration.
In Step 2: Switch over services:
X-Engine is required when you migrate data from the source ApsaraDB RDS for MySQL instance to the destination PolarDB cluster. Therefore, after you start the migration, check whether X-Engine is used when you create tables in the destination PolarDB cluster. If InnoDB is used, submit a ticket.
After the switchover and before the migration is complete, data is reversely migrated from the PolarDB cluster to the source ApsaraDB RDS for MySQL instance. X-Engine is required when you create tables, which is the same as the engine used when you create tables in the PolarDB cluster.
In Step 2: Switch over services and Step 3: Complete the migration:
In the destination PolarDB cluster, InnoDB instead of X-Engine is used when you create tables. If you want to create tables that use X-Engine, specify
engine=xenginewhen you execute DDL statements to create tables.To use X-Engine as the default engine for tables, set the
default_storage_engineparameter toxenginein the PolarDB console.NoteAfter you modify the default_storage_engine parameter, you must restart all nodes in the cluster for the new parameter value to take effect. Before you restart the nodes, make sure that your services will not be adversely affected. Proceed with caution.