PolarDB:Upgrade steps

Pre-upgrade checks

(Optional) Intelligent stress testing

Before performing a major engine version upgrade, use intelligent stress testing to simulate your service traffic running on the destination PolarDB cluster. This helps you:

• Verify whether your cluster specifications need scale-out to handle peak service traffic.

• Analyze performance differences in SQL template execution between the original and destination PolarDB clusters.

For detailed steps, see Traffic playback and stress testing.

Step 1: Upgrade and migrate from PolarDB

In this step, you will create a cluster with the same data as the source PolarDB for MySQL cluster, and incremental data from the source PolarDB for MySQL cluster will be synchronized to this cluster in real time.

1. Log on to the PolarDB console.

2. On the cluster list page, click Create Cluster to go to the cluster purchase page.

3. Select a billing method: Subscription , Pay-as-you-go , or Serverless .

   • Subscription: Pay for compute nodes upfront when creating the cluster. Storage space is billed hourly based on actual usage and deducted from your account hourly.

   • Pay-as-you-go: No upfront payment. Both compute nodes and storage space (based on actual usage) are billed hourly and deducted from your account hourly.

   • Serverless: No upfront payment. Compute nodes, storage space, database proxy, and other resources scale dynamically based on actual demand during cluster usage, and you are billed based on actual usage.

4. Set the following parameters based on your scenario.

   Note

   For parameters not described in the following table, see Purchase a cluster.

   Parameter	Description
   Creation Method	Select Upgrade and Migrate from PolarDB.
   Region	Select the region where the source PolarDB for MySQL cluster resides.
   Source PolarDB Version	The version of the source PolarDB for MySQL cluster. You can select 5.6, 5.7, or 8.0.
   Source PolarDB Cluster	Select the source PolarDB for MySQL cluster.
   Database Engine	The database engine version for the destination cluster. Note When upgrading between versions, you can select the same version as the source cluster or a different version. When upgrading between architectures, you must select MySQL 8.0.
   Database Edition	Matches the source cluster's edition. No selection needed.
   Edition	The series for the destination cluster. Note When upgrading between versions, select Cluster Edition [Recommended]. When upgrading between architectures, select Multi-master Cluster (Limitless).
   CPU Architecture	Matches the source cluster's CPU architecture. No selection needed.
   Nodes	Matches the source cluster's number of workers. No selection needed.
   Selected Specifications	The node specifications for the destination cluster.
   Database Proxy Type	Matches the source cluster's database proxy specifications. No selection needed.

5. In the upper-right corner, review the cluster configuration. Set Subscription Duration (for Subscription clusters), Quantity, and whether to enable Auto-renewal.

6. Read and accept the Service Agreement. Click Buy Now.

7. On the Payment page, confirm the unpaid order details and payment method, then click Place Order .

   Note

   • After successful payment, cluster creation takes 10–15 minutes. You can then see the new cluster in the Cluster List .

   • If cluster nodes show Creating , the cluster is not ready. Only when the cluster status is Running can you use it.

   • Ensure you selected the correct region. Otherwise, you won't see your cluster.

8. After the cluster is created, click the cluster ID to go to the Basic Information page.

9. In the Basic Information page, under the PolarDB Upgrade section, confirm that the destination PolarDB cluster's Replication Latency is less than 60 seconds before proceeding.

   Note

   • Clusters with existing DTS two-way synchronization cannot be upgraded with one click and may experience data inconsistency .

   • After cluster creation, DTS starts syncing data from the source PolarDB cluster. You must complete the upgrade within 30 days. After 30 days, the upgrade feature is automatically disabled.

   • You can click Cancel Upgrade in this section. For impacts of canceling an upgrade, see FAQ.

   • If the status shows Precheck Failed , resolve the issue based on the Error Message .

     For example, if triggers are created in the source PolarDB cluster, the precheck fails and returns the error “PolarDB cluster contains triggers”. Delete the triggers in PolarDB first, and then click Continue Upgrade , or click Abandon Upgrade and manually create a migration task in the DTS console. For more information, see How to configure a synchronization or migration job when triggers exist in the source database.

   • For architecture upgrades, the default write endpoint of the destination cluster is the RW node with MasterID=1. To ensure normal DTS data sync, always write to this RW node until the upgrade completes.

Step 2: Address alignment (optional)

PolarDB major engine version upgrade supports address-preserving switching. You can retain the original database endpoint and switch to the new PolarDB without your application modifying any connection configuration. Note that mutual switching is supported only for endpoints that exist on both the source PolarDB and the target PolarDB cluster. By default, the target creates only a private primary endpoint and a private cluster endpoint. If the source contains more than two endpoints, you must create the corresponding endpoints on the target before switching; otherwise, the switch will not occur. For information about how to create endpoints for a PolarDB cluster, see Manage connection addresses.

Step 3: Upgrade switch

Perform the upgrade switch when the destination PolarDB cluster's replication delay is less than 60 seconds.

1. Log on to the PolarDB console.

2. Find the destination cluster and click its cluster ID.

3. On the Basic Information page, in the PolarDB Upgrade section, click Upgrade Switchover.

   Note

   • Upgrades typically complete within 5 minutes.

   • This operation swaps the read/write status of the source PolarDB cluster and the target PolarDB cluster by changing the source PolarDB cluster to read-only and the target PolarDB cluster to read/write. Meanwhile, DTS reverses the data replication direction by synchronizing new data from the target PolarDB cluster to the source PolarDB cluster.

4. In the Upgrade Switchover dialog box, choose either Switch with Address (No Application Configuration Changes) or Switch without Address (Update Application Connection Configuration to New PolarDB Endpoint) . The dialog shows the mapping between Source PolarDB Endpoints and Destination Endpoints.

   • If you choose Switch with Address (No Application Configuration Changes) , follow these steps:

     1. Select Switch with address swap (no application connection configuration changes required) . The system will automatically swap the connection endpoints on the source PolarDB and the target PolarDB, so you don't need to modify any configuration in your application to automatically connect to the target PolarDB cluster.

        Important

        • Before selecting Switch with Address (No Application Configuration Changes) , read Address switching considerations.

        • If the PolarDB cluster being upgraded is already a source or destination in an existing Data Transmission Service (DTS) task, update the DTS task after the upgrade to use the upgraded PolarDB cluster as the source or destination. This applies to data sync tasks, data migration tasks, and change tracking tasks. For details, see Modify DTS task objects.

     2. Click OK .

   • If you choose Switch without Address (Update Application Connection Configuration to New PolarDB Endpoint) , follow these steps:

     1. Select Switch without Address (Update Application Connection Configuration to New PolarDB Endpoint) .

     2. Click OK .

     3. Refresh the page. Once the destination PolarDB cluster's Read/Write Status shows Read/Write , update your application's database endpoint immediately.

Step 4: Source instance DTS task switch (optional)

1. Go to the PolarDB console.

2. Find the destination cluster and click its cluster ID.

3. On the Basic Information page, in the Apsara PolarDB Migration Feature section, click Source Instance DTS Task Switchover.

4. In the Switch Business DTS Database dialog box, select either Source Instance DTS Task (Forward Switchover) or Destination Instance DTS Task (Switchover Rollback).

   Important

   Before switching, check the DTS sync status for both source and destination instances. For details on checking DTS status, see Check DTS status.

   Source instance DTS task (forward switch)

   If you select Source Instance DTS Task (Forward Switchover), follow these steps. The DTS task list appears, showing columns such as DTS Task Name, Sync Status, Source Instance, and Destination Instance.

   1. Select the DTS task whose database instance you want to switch.

   2. Click Commit Forward Switchover.

   Destination instance DTS task (rollback switch)

   If you select Destination Instance DTS Task (Switchover Rollback), follow these steps.

   The interface resembles the Source Instance DTS Task (Forward Switch) tab, showing the list of DTS tasks to roll back.

   1. Select the DTS task whose database instance you want to switch.

   2. Click Commit Switchover Rollback.

Step 5: Complete upgrade

After completing Step 1: Upgrade from PolarDB, you must complete the upgrade within 30 days.

1. Log on to the PolarDB console.

2. Find the destination cluster and click its cluster ID.

3. On the Basic Information page, in the PolarDB Upgrade section, click Complete Upgrade.

4. In the Complete Upgrade dialog box, choose whether to disable binary logging for the PolarDB cluster, then click OK .

   Note

   • After clicking OK , the system breaks the sync relationship within 2 minutes, and the upgrade status changes to Sync Disabled .

   • If you choose to disable binary logging, the PolarDB cluster restarts automatically to apply the new configuration.

   • If you no longer need the source PolarDB cluster, you can choose to release the source PolarDB cluster. For more information about releasing a cluster, see Releasing a cluster.

   • If you performed an architecture upgrade, clicking OK in the Complete Upgrade dialog restores the write endpoint to its initial state, where the database randomly assigns an RW node as the write endpoint.

View data sync task details (optional)

If errors or anomalies occur during version upgrade, go to the corresponding DTS data sync task details page to view detailed information.

1. Log on to the PolarDB console.

2. Find the destination cluster and click its cluster ID.

3. On the Basic Information page, in the PolarDB Upgrade section, click the task name under DTS Data Synchronization Task to go to the DTS console's data sync task list.

4. In the data sync task list, find the relevant task to view sync details and task logs.

5. If requirements change during upgrade (for example, if new databases are added to the source PolarDB cluster and need to be included in sync), click Modify Sync Objects to reconfigure.

Upgrade rollback (optional)

Before completing the upgrade, if you find issues such as data abnormalities, you can perform a rollback operation to quickly restore the cluster to its pre-upgrade state (the source PolarDB cluster is read-write, the target PolarDB cluster is read-only, and data from the source PolarDB cluster will be synchronized to the target PolarDB cluster). After the rollback is complete, to continue with the major engine version upgrade, you can start directly from the Step 3: Switch over operation.

1. Log on to the PolarDB console.

2. Find the destination cluster and click its cluster ID.

3. On the Basic Information page, in the PolarDB Upgrade section, click Upgrade Rollback.

4. In the failback dialog box, choose either Failback with Address (No Application Configuration Changes) or Failback without Address (Update Application Connection Configuration to Source Instance Endpoint) .

   • If you choose Failback with Address (No Application Configuration Changes) , follow these steps:

     1. Select Switchback with Address Swapping (No Application Connection Configuration Changes Required) , and the system automatically swaps the connection addresses between the source PolarDB cluster and the target PolarDB cluster, enabling you to automatically switch back to the source PolarDB cluster without modifying any configurations on the application side.

     2. Click OK .

        At this point, the source PolarDB cluster is readable and writable, the target PolarDB cluster is read-only, and data from the source PolarDB cluster will be synchronized to the target PolarDB cluster.

        Note

        For architecture upgrade rollback, you can choose which addresses to roll back.

   • If you choose Failback without Address (Update Application Connection Configuration to Source Cluster Endpoint) , follow these steps:

     1. Select Failback without Address (Update Application Connection Configuration to Source Cluster Endpoint) . After failback, update your application's database connection pool endpoint immediately.

     2. Click OK . The source PolarDB cluster becomes read/write, the target PolarDB cluster becomes read-only, and data from the source PolarDB cluster is synchronized to the target PolarDB cluster.

     3. Refresh the page, and when the status of the source PolarDB cluster changes to read/write, promptly update the database endpoint in your application to that of the source PolarDB cluster.

Cancel upgrade (optional)

1. Log on to the PolarDB console.

2. Find the destination cluster and click its cluster ID.

3. On the Basic Information page, in the PolarDB Upgrade section, click Cancel Upgrade.

4. In the Cancel Upgrade dialog box, click OK. The dialog explains that canceling the upgrade breaks data sync between source and destination clusters. Optionally, select Disable Binary Logging for Destination Instance.

FAQ

SELECT * FROM information_schema.triggers;

SELECT TRIGGER_SCHEMA,concat('DROP TRIGGER ',TRIGGER_SCHEMA,'.',TRIGGER_NAME,';') FROM information_schema.triggers;

+----------------+-------------------------------------------------------------+
| TRIGGER_SCHEMA | concat('DROP TRIGGER ',TRIGGER_SCHEMA,'.',TRIGGER_NAME,';') |
+----------------+-------------------------------------------------------------+
| test_triggers  | DROP TRIGGER test_triggers.xxx_insert;                      |
| test_triggers  | DROP TRIGGER test_triggers.xxx_update;                      |
| test_triggers  | DROP TRIGGER test_triggers.xxx_delete;                      |
+----------------+-------------------------------------------------------------+