PolarDB:Overview

Introduction

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.

• You can upgrade an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster that runs the same or a different MySQL version. 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.

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.

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 upgrade is free of charge within 30 days. The free trial is not available for virtual network operator (VNO) accounts and RAM users.

• No data loss occurs during migration.

• Incremental data migration is supported. The service downtime is less 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.

• If migration fails, you can roll back the migration. The rollback can be completed within 10 minutes.

Prerequisites

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

  • If you use physical migration, we recommend that you set the retention period of local binary logs to a minimum of 24 hours.

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

• If you perform the upgrade by using a DTS data synchronization task, delete the triggers that are created for the source ApsaraDB RDS for MySQL instance. Otherwise, the migration is interrupted. For more information, see Configure a data synchronization or migration 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.

• You cannot migrate an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster that is used by a DTS two-way data synchronization task.

• The physical migration method is subject to the following limits:

  • Cross-region data synchronization 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 synchronization is not supported.

  • You cannot configure parameters of the source ApsaraDB RDS for MySQL instance during data migration.

  • Only databases, tables, views, stored procedures, and functions can be migrated. Events cannot be migrated.

  • The source ApsaraDB RDS for MySQL instances is subject to the limits listed in the following table.

    Item

    Description

    Limits on the source instance

    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 exceptional circumstances, data inconsistency or loss may occur. Make sure that you set 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.

  • The following table describes the 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 following table describes the other limits.

    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 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 tablespace used by the destination database is larger than that used by 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:

  • Step 4: Complete the migration is complete.

    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. The free trial is not available for virtual network operator (VNO) accounts and RAM users.

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

  • Step 4: Complete the migration is complete.

    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. You are charged for data migration and synchronization that is implemented by using DTS after 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

When you upgrade an ApsaraDB RDS for PostgreSQL instance to a PolarDB cluster, you can select Switch with Endpoints (Connection Changes Not Required). Then, the system exchanges the endpoints between the ApsaraDB RDS for PostgreSQL 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 ApsaraDB RDS for MySQL instance and the PolarDB cluster.

To perform switchover 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 are not interchanged.

• Endpoints can be interchanged only if both the source ApsaraDB RDS for MySQL instance and the destination PolarDB cluster have the endpoints. By default, the destination PolarDB cluster has only a private primary endpoint and a private cluster endpoint. If the source ApsaraDB RDS for MySQL instance has more endpoints, you must create corresponding endpoints on the destination PolarDB cluster if you want to interchange these endpoints. For information about how to create an endpoint for a PolarDB cluster and an ApsaraDB RDS for MySQL instance, see Manage endpoints and Configure endpoints for an RDS instance.

• The primary endpoint of the source ApsaraDB RDS for MySQL instance is always switched during the endpoint switchover process. You can choose to exchange the primary endpoint of the source ApsaraDB RDS for MySQL instance with the primary endpoint or default cluster endpoint of the destination PolarDB cluster. The dedicated proxy endpoint and read-only endpoint of the ApsaraDB RDS for MySQL instance can be interchanged with the default cluster endpoint and custom endpoint of the PolarDB cluster. You can specify whether to perform endpoint switchover and select the endpoint pairs to interchange. A PolarDB cluster can have up to seven cluster endpoints. Therefore, up to seven dedicated proxy endpoints or read-only endpoints of the ApsaraDB RDS for PostgreSQL instance can be exchanged with the cluster endpoints of the PolarDB cluster.

• After incremental synchronization is complete, the destination cluster enters the running state. Before exchanging the endpoints, you can configure parameters, add read-only nodes add address settings.

• Before you switch private endpoints, make sure that the source ApsaraDB RDS for PostgreSQL instance and the destination PolarDB cluster belong to the same virtual private cloud (VPC). Otherwise, the original services cannot be connected after the switchover.

• If you want to use Data Management (DMS) to log on to the PolarDB cluster after the endpoints are interchanged, make sure that you specify the correct cluster ID and 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