Overview - PolarDB - Alibaba Cloud Documentation Center

This topic describes the solutions, prerequisites, limits, and billing rules for the upgrades of PolarDB for MySQL clusters.

Solutions

PolarDB for MySQL allows you to upgrade PolarDB for MySQL clusters between different versions and editions. The destination PolarDB for MySQL cluster retains the accounts, databases, IP whitelists, and required parameters of the source PolarDB for MySQL cluster.

Version upgrades
For example, you can upgrade a PolarDB for MySQL 5.6 cluster to a PolarDB for MySQL 5.7 cluster, or upgrade a PolarDB for MySQL 5.6 cluster to a PolarDB for MySQL 8.0.1 cluster.
Edition upgrades
You can upgrade a cluster of PolarDB for MySQL Cluster Edition or Single Node Edition to a cluster of PolarDB for MySQL Multi-master Cluster (Database/Table) Edition.

For more information, see Procedure.

Benefits

The endpoints of the source cluster are retained. You can switch to the new version without the need to change the connection settings of your applications.
The upgrade is free of charge.
No data loss occurs during the upgrade.
Incremental data migration is supported. This allows you to migrate data with a service downtime of less than 10 minutes.
Hot upgrades are supported. Only one transient connection occurs during the upgrade.
Rollback is supported. If the upgrade fails, the cluster can be restored within 10 minutes.

Prerequisites

PolarDB for MySQL clusters of Cluster Edition or Single Node Edition are used.

Limits

Type	Description
Limits on the source database	Bandwidth requirements: The server to which the source database belongs must have sufficient egress bandwidth. Otherwise, the upgrade speed is affected. The tables to be migrated must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate data records. To perform incremental migration, you must enable the binary logging feature. You must also set the `loose_polar_log_bin` parameter to ON in the PolarDB console. Otherwise, an error message is returned during the precheck and the upgrade task cannot be started. Note For both a full data and incremental data migration task, the binary logs of the source database must be stored for at least seven days. After a full data migration is completed, 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 specify the retention period of binary logs based on the preceding requirements. Otherwise, the service reliability and performance stated in the Service Level Agreement (SLA) of DTS cannot be achieved. Limits on operations to perform on the source database: During schema migration and full data migration, do not perform DDL operations to change the schemas of databases or tables. Otherwise, the data migration task fails.
Limits on SQL statements	The following DML operations are supported: INSERT UPDATE DELETE The following DDL operations are supported: 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
Other limits	Before you migrate data, evaluate the impact of data migration on the performance of the source and destination databases. We recommend that you migrate data during off-peak hours. During full data migration, 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 migration, concurrent INSERT operations cause fragmentation in the tables of the destination database. After a full data migration is completed, the size of the used tablespace of the destination database is larger than that of the source database. Make sure that the precision settings for columns of the FLOAT or DOUBLE data type meet your business requirements. DTS uses the `ROUND(COLUMN,PRECISION)` function to retrieve values from columns of the FLOAT or DOUBLE data type. If you do not specify a precision value, DTS sets the precision for the FLOAT data type to 38 digits and the precision for the DOUBLE data type to 308 digits. DTS attempts to resume data migration tasks that failed within the last seven days. Before you switch workloads to the destination cluster, stop or release the data migration task. You can also run the `revoke` command to revoke the write permissions from the accounts that are used by DTS to access the destination cluster. Otherwise, the data in the source database overwrites the data in the destination cluster after the task is resumed.
Other issues	DTS regularly executes the `CREATE DATABASE IF NOT EXISTS 'test'` statement in the source database to move forward the binary log file position.

Usage notes

If a trigger is created in the source cluster, check whether the trigger causes data inconsistency between the source and destination clusters.
- If you ensure that the trigger does not cause data inconsistency, after a trigger error occurs during the precheck, you can click Continue Upgrade and skip the trigger check.
- If data inconsistency may occur, you can delete the trigger and then click Continue Upgrade. You can also click Cancel and then manually create a migration 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 source cluster and you select Switch with Endpoints, make sure that SSL is enabled for the endpoint of the destination cluster.
You cannot upgrade the version of a cluster that is added to a global database network (GDN).
SSL is not supported for the endpoints of clusters of PolarDB for MySQL Multi-master Cluster (Database/Table) Edition. Therefore, if you perform an edition upgrade for a source cluster with SSL enabled on its endpoint to a cluster of Multi-master Cluster (Database/Table) Edition, switch with endpoints is not supported.

Billing rules

You are not charged additional fees during the major version upgrade of a cluster based on the following rules:
- You are not charged for data migration and synchronization that is implemented by using Data Transmission Service (DTS).
- If you want to upgrade a pay-as-you-go cluster, you are not charged for the cluster during the upgrade. You are charged for the cluster based on the pay-as-you-go billing method in the following scenarios:
  - The upgrade is complete. For more information, see Procedure.
    Note
    When the data synchronization between the source and destination clusters stops, the upgrade is complete.
    The upgrade must be completed within 30 days.
  - The upgrade is stopped. For example, when the precheck fails or when the cluster is being upgraded, the upgrade is canceled.
    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 you no longer need a subscription cluster for which you have upgraded the major version, you can apply for unsubscription refunds to reduce resources and costs. For more information, see Unsubscription refunds after upgrade.

Switch with endpoints

The switch with endpoints feature is supported when you upgrade a PolarDB for MySQL cluster. The system automatically switches the endpoints of the source and destination clusters. The following figures show the endpoint mapping.

Endpoint mapping for version upgrades
Endpoint mapping for edition upgrades
Edition upgrade allows you to specify the endpoints of the source and destination clusters to be switched. For example, you can switch between the primary endpoint of the source cluster and the cluster endpoint of the destination cluster, between the primary endpoint of the source cluster and the custom endpoint of the destination cluster, and between the cluster endpoint of the source cluster and the custom endpoint of the destination cluster. The following figure shows the internal mapping of endpoints.

When you use the switch with endpoints feature, take note of the following points:

Only the endpoints of the source and destination clusters are switched. The other configurations such as the vSwitches and virtual IP addresses remain the same as before.
Endpoints can be switched only if both the source and destination clusters have endpoints. By default, only the primary endpoint in the internal network is switched.
If you select switch with endpoints for a version upgrade, the primary endpoints of the source and destination clusters are switched. You can choose whether to switch multiple groups of endpoints.
If you select switch with endpoints for an edition upgrade, you can specify the endpoints of the source and destination clusters to be switched. You can choose whether to switch multiple groups of endpoints.
To switch other types of endpoints, you must create the endpoints in advance. For more information about how to create endpoints for a PolarDB cluster, see Manage the endpoints of a cluster.
The ports are not switched when the endpoints are switched. Make sure that the port of the source cluster is the same as that of the destination cluster. By default, port 3306 is used for PolarDB clusters. For more information about how to modify ports, see Change the endpoint and port number.
After the endpoints are switched, issues may occur due to the expiration of the DNS cache data. The databases in the PolarDB cluster may fail to be connected or support only read operations. To resolve this issue, we recommend that you refresh the DNS cache.
If the cluster that you want to upgrade is the source or destination of a task created in the DTS console, you must recreate the task after the upgrade. Such tasks include data synchronization tasks, data migration tasks, and change tracking tasks. For more information about how to create a DTS task, see What is Data Transmission Service?