ApsaraDB RDS:Upgrade database version

RDS editions

ApsaraDB RDS for SQL Server comes in three editions, each with a different availability architecture:

• RDS Basic Edition: Single primary instance with no hot standby. Spec changes and version upgrades cause extended downtime.

• RDS High-availability Edition: Primary and secondary instances in semi-synchronous or asynchronous replication. Automatic failover on primary failure.

• RDS Cluster Edition: Always On architecture with compute-storage separation. Supports one or more read-only instances for read/write splitting.

The features available to you depend on both the SQL Server version and the RDS edition. See Features by SQL Server version and RDS edition for a full comparison.

Limitations

The following instance types cannot be upgraded:

• Instances joined to Active Directory (AD) domains. See Join an RDS SQL Server instance to a self-managed domain.

• Serverless instances. See Overview.

• Instances on the classic network. See Change the network type.

• Read-only instances.

• Primary instances that have read-only instances and run RDS Cluster Edition. See Create a read-only ApsaraDB RDS for SQL Server instance.

Upgrade impacts

Plan your upgrade window by understanding what changes and what stays the same.

What changes:

• The virtual IP address (VIP) of your instance changes. Use the instance endpoint — not the IP address — in your application connection strings to handle VIP changes transparently.

• Approximately 20 minutes of downtime occurs during the workload switchover. Make sure your application is configured to reconnect automatically.

• After the upgrade, flush cached DNS records on your database client. For JVM-based applications, set networkaddress.cache.ttl to 60 seconds or less in $JAVA_HOME/jre/lib/security/java.security, or configure the following in your application's initialization code before the first call to InetAddress.getByName():

  java.security.Security.setProperty("networkaddress.cache.ttl", "60");

• Active Data Transmission Service (DTS) tasks stop during the upgrade. Reconfigure and restart them after the upgrade. See What is Data Transmission Service?

What stays the same:

• Instance name, connection port, tags, and database accounts remain unchanged.

Other notes:

• Once started, an upgrade cannot be cancelled.

• The upgrade duration depends on your data volume. See Estimated duration.

Prerequisites

Before you begin, ensure that you have:

• An ApsaraDB RDS for SQL Server instance

• (Recommended) A pay-as-you-go or serverless RDS instance with the target specifications to test application compatibility before upgrading

Upgrade an instance

1. Go to the Instances page. In the top navigation bar, select the region where your instance resides. Find the instance and click its ID.

2. In the Configuration Information section of the Basic Information page, click Upgrade Version. In the dialog box that appears, click OK.

   If Upgrade Version is not displayed, check whether your instance meets the upgrade requirements listed in Limitations.

   

3. On the Upgrade Engine Version page, configure the following parameters. For other parameter details, see Procedure.

   Some major engine versions and RDS editions may be unavailable depending on your instance's current configuration. See Upgrade rules and Limitations.

   Parameter	Description
   Upgrade To	The target major engine version. The available options for Edition and Instance Type depend on this selection. See Upgrade rules.
   Edition	The target RDS edition. Basic Edition: Single primary instance; compute and storage are decoupled. High-availability Edition: Primary and secondary instances in high availability mode. Cluster Edition: Primary and secondary instances in high availability mode; secondary instances are readable. For a full comparison, see Overview.
   Instance Type	Each instance type specifies the number of CPU cores, memory capacity, maximum connections, and maximum IOPS.
   Switching Time	Switch Immediately After Data Migration: Workloads switch as soon as data migration completes. Switch Within Maintenance Window: Workloads switch during the next scheduled maintenance window.

4. Read and accept the Terms of Service, then click Confirm Order.

The instance status changes to Upgrading Version. When the status returns to Running, the upgrade is complete.

Estimated duration

The total upgrade time depends on your data volume and whether a full backup was taken within the past 36 hours.

SQL Server Web instances do not support backup compression. Backup and restoration speeds may be less than 100 GB per hour.

The backup speed may vary based on the region and time period. To obtain more accurate information about backup and restoration performance, refer to the data volume and time for the last upgrade.

Example: An instance with 4 CPU cores, 8 GB of memory, and 600 GB of data:

• If no full backup was taken within 36 hours: ~6 hours 34 minutes total

• If a full backup was taken within 36 hours: ~3 hours 34 minutes total

To reduce total upgrade time, take a full backup before starting the upgrade or within 36 hours before initiating the task. See Back up an ApsaraDB RDS for SQL Server instance.

Applying incremental transaction logs is resource-intensive. On small instances (such as 2 CPU cores and 4 GB of memory), high transaction log volume can slow restoration speeds. For SQL Server 2019 and later, enabling the Accelerated Database Recovery option can reduce database restoration time. Evaluate this option using Microsoft's official documentation.

Best practices

Schedule during off-peak hours. Upgrade during periods of low transaction volume to minimize impact.

Avoid long-running transactions. Do not run operations such as index creation, index rebuilds, or data archiving during the upgrade. These generate large transaction logs and can significantly extend the database restore phase.

FAQ

Billing

For upgrade pricing, see Change instance specifications.

API reference

To upgrade via API, use ModifyDBInstanceSpec.