PolarDB for MySQL supports automatic upgrade of minor engine versions. After you enable it, the system schedules upgrade tasks for eligible clusters so that they promptly receive version optimizations, feature enhancements, and issue fixes.
This topic describes the applicability, version selection rules, policy settings, and upgrade event management for automatic upgrades. To manually upgrade the database engine or database proxy, see Minor version management.
How it works
After you enable automatic upgrades, the system checks whether a higher minor engine version that meets the conditions is available for the cluster and attempts to schedule an upgrade task. The system then periodically checks eligible clusters.
Automatic upgrades are not performed on all clusters immediately after a new version is released. Whether a task is issued depends on conditions such as the target version, cluster status, existing tasks, and feature availability.
Target version selection
The system selects a compatible target version based on conditions such as the database version branch, product specifications, and processor architecture of the cluster, and automatically matches a stable version (Stable) or a long-term support version (LTS) based on the cluster architecture. The system attempts to schedule an upgrade only when the current minor engine version of the cluster is lower than an eligible target version. Automatic upgrades do not perform major version upgrades across database version branches.
Task scheduling rules
A new automatic upgrade task may not be created in the following cases:
No eligible higher minor engine version is available.
An upgrade event already exists that is awaiting notification, awaiting a time setting, awaiting execution, or running.
An upgrade event recently succeeded or was canceled, and the system-defined cooldown period has not elapsed.
The cluster status, maintenance window, or feature availability conditions do not meet the requirements.
The system schedules upgrade tasks based on configurations such as the maintenance window. For the actual time schedule, see the page. Use the Start Time, Scheduled Switchover Time, and Deadline shown there as the definitive values.
Changing the upgrade policy does not cancel scheduled upgrade tasks. To cancel the current upgrade, handle it separately in View and manage upgrade events.
Applicability
Automatic upgrades are performed at the cluster level and select a compatible minor version within the current database version branch. They are not used for major version upgrades. You cannot enable automatic upgrades for the following clusters:
Clusters deployed across three zones.
The primary and secondary clusters in a Global Database Network (GDN).
Clusters that use the x86 (Hygon) architecture.
Multi-master clusters (Limitless).
Whether other clusters support automatic upgrades also depends on the architecture, version branch, and feature availability. The options actually displayed in the console prevail.
Upgrade impacts and precautions
Minor version upgrades may cause transient connection interruptions and restrict some change operations during the upgrade. For information about upgrade impacts and connection protection, see the precautions in Minor version management.
When you enable and use automatic upgrades, also note the following:
Automatic upgrades do not cross database version branches, which also means that the database proxy (Proxy) is not upgraded at the same time.
Enabling automatic upgrades does not immediately perform an upgrade, and a successfully saved policy does not mean that an upgrade task has been created or that the upgrade has completed.
After you enable automatic upgrades, we recommend that you still periodically check the cluster version and Scheduled Events, and handle them in a timely manner based on your business schedule.
Disabling automatic upgrades or changing the policy to Manual Upgrade does not cancel existing scheduled events. To cancel the current upgrade, handle the event separately in .
Canceling an event does not disable the automatic upgrade policy. The system may schedule another upgrade later when the conditions are met.
Set an automatic upgrade policy
You can select the minor version upgrade method when you create a cluster, and you can change the upgrade policy after the cluster is created. To receive upgrade scheduling notifications, in the Message Center, configure the notification method and recipients for ApsaraDB Fault or Maintenance Notifications. For the procedure, see View and manage scheduled events.
Configure the policy when creating a cluster
Go to the PolarDB for MySQL cluster creation page and complete the basic cluster configurations.
Expand More Configurations (Optional).
In Minor Version Upgrade Options, select an upgrade method:
Manual Upgrade: Upgrade the minor engine version on your own schedule.
Automatic Upgrade: The system schedules a minor engine version upgrade task for the cluster when the upgrade conditions are met.
NoteFor businesses with strict requirements on change windows, we recommend that you choose Manual Upgrade, and schedule upgrade times yourself. For businesses that want to continuously receive version optimizations and issue fixes and accept execution scheduled by the system during the maintenance window, we recommend that you choose Automatic Upgrade.
Complete the other configurations and create the cluster.
Change the policy of an existing cluster
Log in to the PolarDB console，In the navigation pane on the left, click Clusters. Select the Region where the cluster is deployed, and then click the cluster ID to go to the cluster details page。
In the left-side navigation pane, choose Settings and Management > Version Management.
In Minor Version Upgrade tab, in the Version Information section, view the current Minor Version Upgrade Policy and click Set.
Select Automatic Upgrade or Manual Upgrade, confirm the change, and save the settings. After the settings are saved, Version Information section's Minor Version Upgrade Policy shows the selected upgrade method.
After you enable automatic upgrades, the system checks the upgrade conditions and schedules tasks. Upgrades are not performed immediately.
Saving the policy only means that the configuration is updated. It does not mean that an upgrade task has been created. Continue to check Scheduled Events and the current cluster version.
Changing the policy to Manual Upgrade does not cancel scheduled tasks. To cancel the current upgrade, handle it separately in .
Upgrade Version section, Upgrade Now, Upgrade in Maintenance Window, and Scheduled Upgrade are used to initiate a one-time upgrade. These operations are different from setting an automatic upgrade policy.
View and manage upgrade events
Log on to the PolarDB console.
In the left-side navigation pane, choose , and select the region where the cluster resides.
Find the Minor Version Upgrade event for the target cluster, and view the event details and schedule.
Depending on the operations allowed for the event, adjust the execution time or cancel the event before execution.
For events in the Waiting Setting Time state, you must set the execution time before the Deadline. Events that are still not set after this time are canceled and are not automatically executed.
After an event enters the Executing state, you cannot intervene manually by using regular event operations.
Canceling the current event does not disable the automatic upgrade policy. The system may schedule another upgrade later when the scheduling conditions are met.
For event states and operation rules, see View and manage scheduled events.
View upgrade results
After the upgrade is complete, go to the cluster's Settings and Management > Version Management page, and in the Version Information section, confirm that the engine version has been updated to the target minor version after the upgrade. If so, the upgrade is successful. For detailed steps to view the database proxy and engine versions, see Minor version management.
FAQ
Why have I not received an upgrade task after enabling automatic upgrades?
The system must meet the conditions for the target version, cluster status, feature availability, and task deduplication at the same time. If no eligible higher version is available, an upgrade event already exists, or an upgrade event was recently canceled or completed, the system may not issue a new task. First check the current version and scheduled events to confirm whether an upgradeable version exists and whether a task already exists.
Do automatic upgrades cross database version branches?
No. Automatic upgrades select a compatible minor version based on the current version branch of the cluster and are not used for major version upgrades.
Can I specify the target version for automatic upgrades?
The target version for automatic upgrades is selected by the system. To proactively select an upgradeable version or schedule an upgrade, use the manual upgrade feature. The options provided in the console prevail.
After disabling automatic upgrades, do I still need to handle scheduled tasks?
Yes. Changing the upgrade policy does not cancel scheduled tasks. Handle them separately in .
After I cancel an upgrade, will I no longer receive upgrade notifications?
No. Cancellation applies only to the current event and does not disable the automatic upgrade policy. The system may schedule another upgrade later when the scheduling conditions are met.
Does automatic upgrade also upgrade the database proxy (Proxy)?
The policy described in this topic is used for automatic minor engine version upgrades and does not mean that the proxy is also upgraded. To upgrade the proxy separately or at the same time, see Minor version management.
Can I still upgrade manually after enabling automatic upgrades?
Yes. You can still proactively initiate minor version upgrades based on your business schedule. If an automatic upgrade event already exists, check that event as well to avoid duplicate upgrades.
Related topics
Minor version management: View minor engine versions and database proxy versions, and manually initiate upgrades.
View and manage scheduled events: View upgrade event states and schedules, adjust execution times, or cancel events.