PolarDB notifies you of upcoming O&M events — including database software upgrades and hardware maintenance — at least three days in advance. For each scheduled event, you can view its type, task ID, cluster name, and switchover time, and reschedule the switchover to a time that suits your workload.
Prerequisites
Before you begin, ensure that you have:
Access to the PolarDB console
A contact configured in Message Center to receive event notifications (see Set up notifications)
Set up notifications
To receive scheduled event notifications by phone, email, or internal message, configure a contact in Message Center:
Log on to Message Center.
Select ApsaraDB Fault or Maintenance Notifications.
Specify a contact — assign an O&M engineer so that notifications reach the right person.
If no contact is specified, notifications are not delivered.
Figure 1. Message Center notification settings
For questions about a scheduled event, join the PolarDB DingTalk group (group number: 51685000218). The group provides 24/7 chatbot support and expert consultation.
View and reschedule scheduled events
Step 1: Open the Scheduled Events page
Log on to the PolarDB console.
In the upper-left corner, select the region where your cluster is deployed.
In the left-side navigation pane, choose Scheduled Events.
If an event requires you to schedule a handling time, a prompt appears asking you to do so as soon as possible.
Step 2: (Optional) Set a global periodic switching time
The Global Scheduler lets you set a recurring switching time that applies to all new scheduled O&M events, except high-risk vulnerability fix events. If no periodic switching time is set, new events default to the cluster's maintenance window.
On the Scheduled Events tab, click Global Schedule.
In the Global Scheduler panel, configure the periodic switching time and click OK.
The Global Scheduler setting applies to new scheduled O&M events only. Existing events are not affected.
Step 3: Reschedule a specific event
On the Scheduled Events page, locate the cluster you want to manage and click Add Scheduled Time.
In the Add Scheduled Time dialog box, configure Scheduled Switching Time and click OK.
Rescheduling constraints:
| Constraint | Details |
|---|---|
| Latest Start Time | The scheduled switching time cannot be later than the Latest Start Time shown for the event. |
| Earliest Execution Time | Select this option to use the system-determined earliest possible date and time. The event moves to pending status immediately after you click OK. If you clear Set the earliest execution time, you can change the scheduled switching date and time. |
Event types and impacts
The following table describes the causes and business impacts of each scheduled event type. Use this to decide when to schedule the switchover.
| Upgrade type | Event sub-type | Impact | Details |
|---|---|---|---|
| Hot upgrade | Instance migration — triggered by host security vulnerabilities, hardware warranty expirations, or OS upgrades; migrates clusters (including non-high-availability clusters and read-only clusters) to a new server | Transient connections | Clusters or data shards experience transient connections and enter a read-only state for up to 30 seconds while data synchronizes. Perform the switchover during off-peak hours and make sure your application reconnects automatically. Data Management (DMS) and Data Transmission Service (DTS) are temporarily unavailable during the switchover. |
| Hot upgrade | Switching between primary and read-only nodes — triggered by host security vulnerabilities, hardware warranty expirations, or OS upgrades; switches workloads of high-availability clusters from primary nodes to read-only nodes | Transient connections | Same impact as instance migration above (up to 30 seconds read-only). |
| Hot upgrade | Cluster parameter adjustment — triggered by known parameter risks during scheduled O&M; modifies cluster parameters | May restart | If the modified parameter requires a restart, the cluster restarts automatically. |
| Hot upgrade | Host vulnerability fixing — triggered to fix vulnerabilities on the host where your cluster runs | — | — |
| Hot upgrade | Backup mode change — triggered to switch a cluster from logical backup to physical backup | — | — |
| Hot upgrade | Minor engine version update — triggered to update your cluster to a new minor version with additional features, bug fixes, and improvements | Transient connections | Same impact as instance migration above (up to 30 seconds read-only). Check for differences between your current minor version and the target version. |
| Hot upgrade | — triggered to update proxy nodes to a new minor version | Transient connections | Same impact as instance migration above (up to 30 seconds read-only). Check the PolarProxy release notes for version differences. |
| Hot upgrade | Network upgrade — triggered to upgrade network facilities, improving network performance and stability | Transient connections | Same 30-second read-only impact. Some network upgrades involve cross-zone migrations that change the virtual IP address of a cluster. If your client connects using a virtual IP address rather than the cluster's domain-name endpoint, the connection is interrupted. To avoid this, use the domain-name endpoint provided by your cluster and disable DNS caching on the application server. |
| Hot upgrade | Storage gateway upgrade — triggered to upgrade storage gateways, improving storage performance and stability | I/O jitter | Temporary I/O jitter and increased SQL latency for no longer than three seconds. |
| Cold upgrade | Public preview version upgrade — used in special scenarios such as upgrading public preview versions to official versions | Transient connections | Clusters or data shards experience transient connections and enter a read-only state for up to two minutes. If your cluster has many table files, is running large transactions, or has high CPU utilization before the upgrade, the downtime may exceed two minutes. Perform the upgrade during off-peak hours and make sure your application reconnects automatically. To ensure data security, back up your data before you upgrade major versions or public preview versions. |
In most cases, the system switches your workloads to a read-only node before an event occurs. The actual switchover happens within the maintenance window after the scheduled switching time.
API reference
| API | Description |
|---|---|
| DescribePendingMaintenanceActions | Queries the number of scheduled events by task type |
| DescribePendingMaintenanceAction | Queries the details of scheduled events |
| ModifyPendingMaintenanceAction | Modifies the switchover time of a scheduled event |