Frequently asked questions about major version upgrades of PolarDB for MySQL clusters.
Pre-upgrade checks
What do I do if upgrade evaluation checks fail?
Each failed check has a specific fix. Resolve the issue listed for each check item, then re-run the evaluation.
| Category | Check item | How to fix |
|---|---|---|
| Basic information verification | Source instance running status | The source cluster must be in the Running state. |
| Basic information verification | Source instance read/write status | The source cluster must be in the Running state and in Read/Write mode. |
| Basic information verification | Service-linked role for PolarDB | Create the service-linked role for PolarDB. See Pre-check whether the service-linked role for PolarDB is created for instructions, or use the CreateServiceLinkedRole API directly. |
| Migration task dependency verification | DTS permissions | Grant your Alibaba Cloud account permission to access cloud resources over Data Transmission Service (DTS). See Authorize DTS to access Alibaba Cloud resources. |
| Migration task dependency verification | Source instance binary log verification | Enable binary logging on the source cluster before the upgrade. See Enable binary logging. |
| Whether the source instance is empty | At least one database must exist in the source cluster. See Create a database before starting the upgrade. | |
| Source instance trigger verification | Delete any triggers in the source cluster before upgrading. The upgrade will be interrupted if triggers exist. After the upgrade completes, recreate the triggers in the destination cluster. | |
| Tables without primary keys | Tables without primary keys may produce duplicate data in the destination cluster after synchronization. See the SQL query and resolution steps below. | |
| Key information verification | Source instance root account verification | The root and aliyun_root accounts must not both exist in the source cluster simultaneously. Delete the redundant system account before upgrading. See Remove extra system accounts from the source PolarDB for MySQL cluster. |
Identifying and fixing tables without primary keys
Run the following SQL on the source cluster using a privileged account to find tables without primary keys:
SELECT t1.table_schema, t1.table_name
FROM information_schema.TABLES t1 LEFT OUTER JOIN information_schema.TABLE_CONSTRAINTS t2
ON t1.table_schema = t2.TABLE_SCHEMA AND t1.table_name = t2.TABLE_NAME
AND t2.CONSTRAINT_NAME IN ("PRIMARY")
WHERE t2.table_name IS NULL
AND t1.table_type = "BASE TABLE"
AND t1.TABLE_SCHEMA NOT IN ("information_schema", "performance_schema", "mysql", "sys")Add primary keys to the affected tables. If duplicate data is acceptable for your use case, select Continue when the warning appears during the major version upgrade.
Cluster specifications and purchasing
Must the source and destination clusters use the same specifications?
No. Select the specifications for the destination cluster based on your needs. We recommend setting the destination cluster specifications to be equal to or greater than those of the source cluster.
Do I need to purchase a destination cluster before the upgrade?
No. A destination cluster with the same data as the source cluster is automatically created and purchased during the upgrade.
Impact on the source cluster
Does the major version upgrade affect the source cluster?
No. The upgrade does not affect the normal operation of the source cluster.
Does data synchronization affect the performance of the source cluster?
Data synchronization involves querying data from the source cluster, which decreases its query performance during the synchronization period.
Is data lost during the upgrade?
No data is lost. Business downtime is less than 10 minutes. During the downtime, the business is suspended and no incremental data is generated, but the database remains running. You can roll back the migration if needed.
Accounts, settings, and data
Do I need to recreate accounts and passwords in the destination cluster after the upgrade?
No. The destination cluster automatically retains the account settings, databases, IP whitelists, and required parameters from the source cluster.
Endpoint switching
Do I need to update the application endpoint after switching to the destination cluster?
If you select Switch with Endpoints during the upgrade, no changes are needed. The system automatically swaps the endpoints of the source and destination clusters, so your application connects to the destination cluster without any configuration changes.
I selected "Switch with Endpoints," but the destination cluster still uses its new endpoint after the upgrade. Why?
Endpoints can only be switched when both the source and destination clusters have endpoints. By default, only primary endpoints on the internal network are switched. To switch other endpoint types, create the corresponding endpoints on both clusters before starting the upgrade. See Apply for a cluster endpoint or a primary endpoint.
Why can't I connect to the PolarDB cluster — or why is it read-only — after the business switch?
This is typically caused by stale DNS cache data. 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. Refresh your DNS cache to resolve the issue.
Why is the "Complete upgrade" button missing from the console after the upgrade and business switch?
Once you click Complete Upgrade, the button is hidden to prevent duplicate submissions.
Canceling the upgrade
What happens if I cancel the upgrade?
The synchronization link between the source and destination clusters is disconnected, and the two clusters are no longer associated.
The destination cluster becomes readable and writable and is not automatically released. Release the destination cluster promptly if you no longer need it, to avoid additional charges.
If you cancel manually, you can choose whether to disable binary logging on the source cluster. If the upgrade is canceled automatically, binary logging remains enabled.
Disabling binary logging slightly improves write performance. Existing binary logs are retained after disabling. To delete binary logs, first reduce the retention period and wait for automatic deletion, then disable binary logging. After you disable binary logging, the cluster automatically restarts within 5 minutes, causing approximately 40 seconds of service interruption. Restart duration varies based on data volume and number of tables. Disable binary logging during off-peak hours and make sure your application can automatically reconnect to the database.
DTS data synchronization tasks
If a DTS task was running on the source cluster before the upgrade, is it affected?
No. During the upgrade, the system replicates full data from the source cluster to a new PolarDB for MySQL cluster and then synchronizes incremental data. The DTS task's data source remains the source cluster throughout, so migrating data to the new cluster does not affect it.
Use the DTS task switchover feature to modify or replace the source or destination cluster for DTS synchronization or migration tasks during the upgrade, ensuring a smooth business transition.
Security features
Can I upgrade a cluster with SSL enabled?
Yes.
If SSL is enabled on the source cluster, enable SSL on the corresponding endpoint of the destination cluster as well.
Can I upgrade a cluster with Transparent Data Encryption (TDE) enabled?
Yes.
Can I upgrade an SSL-enabled cluster to Multi-master Cluster (Database/Table) Edition?
Yes. However, SSL cannot be enabled on the destination cluster of Multi-master Cluster (Database/Table) Edition.
Can I upgrade a TDE-enabled cluster to Multi-master Cluster (Database/Table) Edition?
Yes. However, TDE cannot be enabled on the destination cluster of Multi-master Cluster (Database/Table) Edition.
Zone availability
What if the cluster's current zone is no longer available? Can I still upgrade?
Yes. Purchase a destination cluster in a different zone within the same region. The data is not affected.