PolarDB for MySQL:Overview

Background information

The upgrade from ApsaraDB RDS for MySQL to PolarDB is implemented by creating a PolarDB for MySQL cluster and migrating the ApsaraDB RDS for MySQL instance to that cluster. The created PolarDB cluster uses the accounts, databases, IP address whitelist, and required parameters of the source ApsaraDB RDS for MySQL instance.

The following section describes the requirements for the engine versions, storage types, and editions of the source ApsaraDB RDS for MySQL instances and for the destination PolarDB for MySQL clusters:

• You can upgrade ApsaraDB RDS High-availability Edition instances that run MySQL 5.6, MySQL 5.7, and MySQL 8.0 to PolarDB for MySQL clusters.
  Note For ApsaraDB RDS for MySQL Basic Edition instances, you must upgrade them to High-availability Edition instances as set out in Upgrade an ApsaraDB RDS for MySQL instance from Basic Edition to High-availability Edition before you upgrade the instances to PolarDB for MySQL clusters.
• ApsaraDB RDS for MySQL instances can be upgraded to PolarDB for MySQL clusters that run the same or different MySQL versions. For example, you can upgrade an ApsaraDB RDS for MySQL 5.6 instance to a PolarDB for MySQL 5.6 cluster, or to a PolarDB for MySQL 8.0 cluster.

Comparison between physical migration and logical migration

The upgrade feature supports two methods: physical migration (physical replication) and logical migration (data synchronization over DTS).

• Physical migration: You can use the physical migration method to copy full data from the source ApsaraDB RDS for MySQL instance. Then, incremental data is synchronized to the destination PolarDB for MySQL cluster.
• Logical migration: You can create a data synchronization task on DTS to migrate the schemas and full data of the source ApsaraDB RDS for MySQL instance to the destination PolarDB for MySQL cluster. Then, incremental data is synchronized to the destination cluster.

The following table compares the physical migration and logical migration methods.

The following table describes the MySQL versions and storage types supported by the two migration methods.

Benefits

The upgrade feature has the following benefits:

• The endpoint of the source database is retained. You can switch to PolarDB without changing the connection settings of your applications.
• The data migration feature is provided free-of-charge.
• No data loss occurs during the migration.
• Incremental data migration is supported. This allows you to migrate data with a service downtime of less than 10 minutes.
• Hot migration is supported. Only a single transient connection occurs during the data migration process.PolarDB
• Migration rollbacks are supported. If a migration fails, the migration can be rolled back within 10 minutes.

Prerequisites

• Source ApsaraDB RDS for MySQL instances must meet the following requirements regardless of whether you use physical migration or logical migration to perform the upgrade:
  • For ApsaraDB RDS for MySQL instances of High-availability Edition that run MySQL 5.6, the minor version must be 20190815 or later.
  • For ApsaraDB RDS for MySQL instances of High-availability Edition that run MySQL 5.7, the minor version must be 20200331 or later.
  • For ApsaraDB RDS for MySQL instances of High-availability Edition that run MySQL 8.0, any minor version can be upgraded.
  Note You can execute the SHOW VARIABLES LIKE '%rds_release_date%'; statement to view the minor version of your ApsaraDB RDS for MySQL instances. If the minor version is earlier than the required version, you can upgrade the minor version to the latest version. For more information, see Update the minor engine version of an ApsaraDB RDS for MySQL instance.
• If you use the logical migration method to perform the upgrade and a trigger is created for the source ApsaraDB RDS for MySQL instance, check whether the trigger will cause data inconsistency between the source instance and destination cluster. If you confirm that the data will remain consistent, you can click Continue to skip the verification when the "The RDS instance has a trigger" error message is reported during the precheck. If data inconsistency may occur, you can delete the trigger and then click Continue. Alternatively, you can click Abandon and then manually create a synchronization task in the DTS console. For more information, see Configure a data synchronization task for a source database that contains a trigger.
• If SSL is enabled for the endpoint of the ApsaraDB RDS for MySQL instance, you select Switch with Endpoints and the endpoint is switched, make sure that SSL is enabled for the endpoint of the PolarDB cluster.
• The table storage engine for the source ApsaraDB RDS for MySQL instance is InnoDB.
• 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 [Important] RDS network link upgrade.

Limits

• The physical migration method is subject to the following limits:
  • Cross-region data migration is not supported.
  • You cannot configure parameters of the source ApsaraDB RDS for MySQL instance during data migration.
• The logical migration method is subject to the following limits:
  • Cross-region data migration is not supported.
  • You cannot configure parameters of the source ApsaraDB RDS for MySQL instance during data migration.
  • 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 split the tables, configure multiple tasks to synchronize the tables, 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 the parameters of an ApsaraDB RDS for MySQL instance. 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 and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

  • Limits on SQL statements:

    Type	SQL statement
    DML	INSERT, UPDATE, and DELETE
    DDL	ALTER TABLE and ALTER VIEW CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, and CREATE VIEW DROP INDEX and DROP TABLE RENAME TABLE TRUNCATE TABLE

  • The limits in the following table also apply.

    Item

    Description

    Other limits

    To ensure compatibility, the version of the destination database must be the same as or later than that of the source database. If the version of the destination database is earlier than that of the source database, database compatibility issues may occur. Before you synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. During initial full data synchronization, DTS uses the read and write resources of the source and destination databases. This may increase the loads on the database servers. During full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. After full data synchronization is complete, the size of the used tablespace of the destination database is larger than that of the source database. During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. For example, if you use tools other than DTS to write data to the destination, data loss may occur in the destination when you use DMS to perform online DDL operations. By default, DTS disables FOREIGN KEY constraints for the destination database in a data synchronization task. Therefore, the cascade and delete operations of the source database are not synchronized to the destination database.

Billing rules

• The following billing rules are applicable to the physical migration method:

  You are not charged for data migration from the source ApsaraDB RDS for MySQL instance to the PolarDB cluster. You are charged only for purchasing the PolarDB cluster. For more information, see Billable items.PolarDB

• The following billing rules are applicable to the logical migration method:

  You are charged for both purchasing PolarDB clusters and creating data synchronization tasks on DTS. However, the upgrade feature is in the free-trial phase. No fees are charged for a synchronization task within 30 days after it is created. The following table describes the billing rules for the logical migration method.

  Migration object	Pricing
  Schema synchronization and full data synchronization	No fees are charged for a synchronization task within 30 days after it is created. After more than 30 days, the synchronization task will be canceled. Note You can log on to the PolarDB console and view the number of remaining days of a synchronization task in the RDS Migration section on the Overview page.
  Synchronize incremental data

Backup policies

• The cycle and start time for automatic data backup on PolarDB are the same as those on ApsaraDB RDS.
• The retention periods of backup files on ApsaraDB RDS and PolarDB:
  • If the retention period of backup files on ApsaraDB RDS is 14 days or less, the retention period of level-1 backup files on PolarDB is the same as that on ApsaraDB RDS.
  • If the retention period of backup files on ApsaraDB RDS is between 14 days (exclusive) and 30 days (inclusive), the retention period of level-1 backup files on PolarDB is fixed to 14 days. The level-2 backup feature is enabled on PolarDB and the retention period of level-2 backup files in the same region is fixed to 30 days. If the retention period of backup files on ApsaraDB RDS is longer than 30 days, the level-2 backup feature is enabled on PolarDB and the retention period of level-2 backup files in the same region is the same as that on ApsaraDB RDS.
  • If the retention period of backup files on ApsaraDB RDS is permanent, the retention period of level-1 backup files on PolarDB is fixed to 14 days. The level-2 backup feature is enabled on PolarDB and the retention period of level-2 backup files is permanent.
• If the high-frequency backup feature is enabled on ApsaraDB RDS, the high-frequency backup feature is also enabled on PolarDB by default. The retention periods of high-frequency backup files on ApsaraDB RDS and PolarDB:
  • If the retention period of high-frequency backup files on ApsaraDB RDS is not longer than 120 minutes, the retention period of high-frequency backup files on PolarDB is fixed to 120 minutes.
  • If the retention period of high-frequency backup files on ApsaraDB RDS is between 120 minutes (exclusive) and 180 minutes (inclusive), the retention period of high-frequency backup files on PolarDB is fixed to 180 minutes.
  • If the retention period of high-frequency backup files on ApsaraDB RDS is longer than 180 minutes, the retention period of high-frequency backup files on PolarDB is fixed to 240 minutes.

Switchover with endpoints (connection changes not required)

When you upgrade an ApsaraDB RDS for MySQL instance to a PolarDB cluster, you can select Switch with Endpoints (Connection Changes Not Required). Then, the system interchanges the endpoints between the ApsaraDB RDS for MySQL instance and the PolarDB cluster. In this case, you do not need to modify the configurations of your applications to connect to the PolarDB cluster. The following figure shows the rules for endpoint interchanges between the ApsaraDB RDS for MySQL instance and the PolarDB cluster.

To switch with endpoints, take note of the following limits:

• Only the endpoints of the ApsaraDB RDS for MySQL instance and the PolarDB cluster are interchanged. The other configurations such as the vSwitches and virtual IP addresses remain the same as before.
• Endpoints can be interchanged only if both the source ApsaraDB RDS for MySQL instance and the destination PolarDB cluster have endpoints. By default, only the primary endpoints in the internal network can be interchanged.
• The primary endpoints of the ApsaraDB RDS for MySQL instance and the PolarDB for MySQL cluster must be interchanged. The dedicated proxy endpoint of the ApsaraDB RDS for MySQL instance may be interchanged with the default cluster endpoint of the PolarDB for MySQL cluster, and the read-only endpoint of the ApsaraDB RDS for MySQL instance may be interchanged with the custom endpoint of the PolarDB for MySQL cluster. You can choose whether to perform the optional interchanges. A single PolarDB for MySQL cluster can contain up to seven cluster endpoints. Therefore, up to seven dedicated proxy endpoints or read-only endpoints of the ApsaraDB RDS for MySQL instance can be interchanged with the cluster endpoints of the PolarDB for MySQL cluster.
• If you want to switch to a different endpoint, you must create the endpoint before the switchover. For more information about how to create endpoints for the PolarDB cluster, see Apply for a cluster endpoint or a primary endpoint. For more information about how to create endpoints for the ApsaraDB RDS for MySQL instance, see Configure endpoints for an RDS instance.
• The port numbers are not interchanged between the ApsaraDB RDS for MySQL instance and the PolarDB cluster. You must make sure that the port number of the ApsaraDB RDS for MySQL instance is the same as that of the PolarDB cluster. The default port number used by ApsaraDB RDS for MySQL and PolarDB is 3306. If the port numbers are different, change one of the port numbers. For more information, see View and change the internal and public endpoints and port numbers of an ApsaraDB RDS for MySQL instance and Modify or delete an endpoint.
• After the endpoints are interchanged, issues may occur due to the expiration of the Domain Name System (DNS) cache data. The databases in the PolarDB cluster may fail to be connected or support only read operations. We recommend that you refresh the DNS cache data of your server to fix this issue.
• If you want to use DMS to log on to the PolarDB database after the endpoints are interchanged, you must use the latest version of DMS and the cluster ID to log on to the database. You cannot log on to the database by using the endpoint.

Related API operations