All Products
Search
Document Center

PolarDB:Overview

Last Updated:Jul 02, 2024

This topic describes the procedure to upgrade an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster, the two upgrade methods and their comparisons, benefits, prerequisites, limits, and billing rules.

Background information

PolarDB allows you to upgrade an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster. A PolarDB for MySQL cluster is automatically created and data is then synchronized to the cluster. The PolarDB cluster uses the accounts, databases, IP address whitelist, and required parameters of the ApsaraDB RDS for MySQL instance.

  • ApsaraDB RDS for MySQL instances can be upgraded to PolarDB for MySQL clusters that run the same or different MySQL versions with one click. 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.

    Note

    The logical migration method is used in the following scenarios: cloning an ApsaraDB RDS for MySQL 8.0 instance, upgrading an ApsaraDB RDS for MySQL instance with cloud disks to a PolarDB for MySQL cluster, and upgrading an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster that runs a different MySQL version. This method is implemented based on the data synchronization capability of Data Transmission Service (DTS). For more information, see Comparison between physical migration and logical migration.

  • You can upgrade the source ApsaraDB RDS for MySQL instance that uses either the subscription or pay-as-you-go billing method to PolarDB for MySQL. The destination PolarDB for MySQL cluster can use the subscription, pay-as-you-go, or serverless billing method.

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.

Note

During the incremental synchronization, all non-InnoDB tables are converted to InnoDB tables.

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.

Comparison

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

Comparison item

Physical migration

Logical migration

Whether DTS is required

No.

Yes.

Whether incremental data migration or synchronization is supported

Yes.

Yes.

Whether operations on the source instance are affected

No.

No.

Whether the source and destination can run different MySQL versions

Source instances must run MySQL 5.6 and 5.7 and use local disks, and destination clusters must run the same MySQL version.

The MySQL versions can be the same or different between the source and destination.

Whether new database accounts must be created in PolarDB clusters after the upgrade

No. The accounts of the source instance are automatically retained in the destination PolarDB cluster.

No. The accounts of the source instance are automatically retained in the destination PolarDB cluster.

Whether new databases can be migrated

Yes.

No.

To migrate a new database, go to the DTS console, modify the object to be migrated, and add the new database to the synchronization task.

Whether structures can be migrated

Yes.

Yes. However, only five types of structures can be migrated: databases, tables, views, stored procedures, and functions.

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

MySQL version

RDS Basic Edition

RDS High-availability Edition

RDS Cluster Edition

5.6

N/A

Local SSD

N/A

5.7

Cloud disk

Local SSD and cloud disk

Cloud disk

8.0

Cloud disk

Local SSD and cloud disk

Cloud disk

Physical migration is used only for upgrading an ApsaraDB RDS for MySQL 5.6 or 5.7 instance of High-availability Edition that uses local SSDs to create a PolarDB for MySQL cluster of the same MySQL version. Logical migration is used for upgrading an ApsaraDB RDS for MySQL instance of other specifications to a PolarDB for MySQL cluster of the same or different MySQL versions.

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. The service downtime is no more than 10 minutes.

  • Hot migration is supported. Only a single transient connection occurs (when business is switched over from the ApsaraDB RDS for MySQL instance to the PolarDB cluster) during the data migration process.

  • Migration rollbacks are supported. If a migration fails, the migration can be rolled back within 10 minutes.

Supported versions

  • When physical migration is used, the source ApsaraDB RDS instance must meet the following requirements. Logical migration is not subject to these requirements.

    • 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.

    Note

    You can execute the SHOW VARIABLES LIKE '%rds_release_date%'; statement to view the minor version of the source ApsaraDB RDS instance. 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.

  • The table storage engine for the source ApsaraDB RDS instance must be InnoDB or X-Engine.

  • If a trigger is created in the source ApsaraDB RDS for MySQL instance when you use the logical migration (data synchronization over DTS) method, 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.

  • 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.

    • 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 synchronize 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 and 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 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.

    • 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

      • 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. This prevents data inconsistency between the source and destination. 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.

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.

  • If the whitelists of the primary and read-only nodes of the source ApsaraDB RDS for MySQL instance are different, you must add the whitelists of the read-only nodes to the whitelists of the primary node in advance to ensure that the whitelists of the read-only nodes can be synchronized to the destination 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 rules

Physical migration

If physical migration is used, you are not charged for data migrations in the upgrade. You are charged only for the destination PolarDB cluster.

  • If the destination PolarDB cluster uses the pay-as-you-go billing method, you are not charged for the cluster throughout the migration process. You are charged on a pay-as-you-go basis after the following operations:

    • After Step 3: Complete the migration.

      Note
      • The migration is complete when the synchronization link between the source instance and the destination cluster is interrupted.

      • The migration must be completed within 30 days.

    • After the migration is stopped (including canceling the migration if the precheck fails and canceling the upgrade during the migration).

      In this case, the destination cluster is already created even if the upgrade is stopped. Release the cluster if you no longer need it. For more information, see Release a cluster.

  • If the destination PolarDB cluster uses the subscription billing method, you need to complete the payment when you create the cluster.

Logical migration

When the logical migration method is used, you are not charged for data migration and data synchronization tasks. You are charged only for the destination PolarDB cluster.

  • If the destination PolarDB cluster uses the pay-as-you-go billing method, you are not charged for the cluster throughout the migration process. You are charged on a pay-as-you-go basis after the following operations:

    • After Step 3: Complete the migration.

      Note
      • The migration is complete when the synchronization link between the source instance and the destination cluster is interrupted.

      • The migration must be completed within 30 days.

    • After the migration is stopped (including canceling the migration if the precheck fails and canceling the upgrade during the migration).

      In this case, the destination cluster is already created even if the upgrade is stopped. Release the cluster if you no longer need it. For more information, see Release a cluster.

  • If the destination PolarDB cluster is a serverless cluster, the destination cluster starts to be billed when it enters the Running state.

  • If the destination PolarDB cluster uses the subscription billing method, you need to complete the payment when you create the cluster.

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 RDS backups are retained for a long term, the PolarDB retention period of level -1 backups is fixed to 14 days. Level -2 backups are retained for a long period of time.

  • 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.

After the migration is complete, you can modify the backup policy in the console as set out in Configure backup settings.

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 endpoints interchange between the RDS 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 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 cluster, and the read-only endpoint of the ApsaraDB RDS for MySQL instance may be interchanged with the custom endpoint of the PolarDB cluster. You can choose whether to perform the optional interchanges. A single PolarDB 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 cluster.

  • If you want to use other endpoints, create the endpoints before the switchover. For more information about how to create endpoints for the PolarDB cluster, see Manage the endpoints of a cluster. For more information about how to create endpoints for the ApsaraDB RDS for MySQL instance, see Configure endpoints for an RDS instance.

  • IPv6 addresses are not supported in switchover with endpoints.

  • 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.

Migration evaluation

The migration evaluation feature is provided by PolarDB to ensure the successful execution of migration tasks and high migration efficiency. This feature allows you to precheck the prerequisites such as the instance status, migration task dependencies, and attributes of the source instance before you upgrade an ApsaraDB RDS for MySQL instance to a PolarDB cluster. This way, you can identify the factors that may affect the migration progress and resolve the issue in advance to reduce the processing and resource costs during migration.

For more information, see Migration evaluation.

Related API operations

Operation

Description

CreateDBCluster

Creates a PolarDB cluster.

Note

If you create a PolarDB cluster by migrating an ApsaraDB RDS for MySQL instance, set CreationOption to MigrationFromRDS.

DescribeDBClusterMigration

Queries the migration state of a specified PolarDB cluster.

ModifyDBClusterMigration

Switches or rolls back the task that migrates data from ApsaraDB RDS to PolarDB.

CloseDBClusterMigration

Cancels or completes the migration for a PolarDB cluster.