This topic describes the solutions, prerequisites, limits, and billing rules for the upgrades of PolarDB for MySQL clusters.
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.
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.
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.
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.
PolarDB for MySQL clusters of Cluster Edition or Single Node Edition are used.
Limits on the source database
Limits on SQL statements
DTS regularly executes the
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.
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?