Upgrade the major engine version of an ApsaraDB RDS for SQL Server instance - ApsaraDB RDS

The features that are provided by different SQL Server versions for each RDS edition are different. You can upgrade the major engine version and RDS edition of your ApsaraDB RDS for SQL Server instance based on your business requirements to obtain more optimized and extended features. For example, you can upgrade the major engine version of an RDS instance from SQL Server 2019 SE to SQL Server 2022 SE and upgrade the RDS edition from RDS Basic Edition to RDS High-availability Edition.

Background information

In RDS Basic Edition, your RDS instance does not have a secondary RDS instance as a hot standby. If your RDS instance unexpectedly exists or you perform operations such as changing the specifications or upgrading the major engine version of your RDS instance, your database service becomes unavailable for a long period of time.

In RDS High-availability Edition, your RDS instance has a secondary RDS instance as a hot standby. Data is synchronized in real time between the primary RDS instance and its secondary RDS instance. If the primary RDS instance fails, your workloads are automatically switched over to the secondary RDS instance. RDS High-availability Edition provides a complete suite of features, such as auto scaling, backup and restoration, performance optimization, and read/write splitting.

RDS Cluster Edition uses the Always On architecture of native SQL Server and supports compute-storage separation. RDS Cluster Edition allows you to create one or more read-only RDS instances to implement read/write splitting. Read-only RDS instances are used to process a large number of read requests.

Note

For more information about the features that are provided by different SQL Server versions on each RDS edition, see Features of ApsaraDB RDS instances that run different SQL Server versions and RDS editions.

Usage notes

After the upgrade, you cannot roll back the major engine version, RDS edition, or instance type of your RDS instance to the original configuration. The following table describes the upgrade rules.

Upgrade rules

Item	Upgrade rule
Major engine version	Upgrade from an SQL Server SE version to an SQL Server EE version Upgrade from an SQL Server SE version to an SQL Server EE (Always On) version Upgrade from an SQL Server Web version to an SQL Server SE version Upgrade from an SQL Server Web version to an SQL Server EE version Upgrade from an SQL Server Web version to an SQL Server EE (Always On) version Note If your RDS instance runs an SQL Server Web version, you must upgrade the SQL Server Web version to an SQL Server SE version and then to an SQL Server EE version or an SQL Server EE (Always On) version.
RDS edition	Upgrade from RDS Basic Edition to RDS High-availability Edition Upgrade from RDS Basic Edition to RDS Cluster Edition Upgrade from RDS High-availability Edition to RDS Cluster Edition
Instance type	Upgrade from a shared instance type to a general-purpose instance type Upgrade from a shared instance type to a dedicated instance type Upgrade from a general-purpose instance type to a dedicated instance type Note If your RDS instance runs RDS High-availability Edition and uses a shared instance type, you cannot directly upgrade the RDS instance to a dedicated instance type on RDS Cluster Edition. You can upgrade your RDS instance only to an instance type that provides the same or higher specifications. For more information about the rules of the upgrade to an instance type that provides higher specifications, see the preceding section. You cannot directly upgrade your RDS instance from a shared instance type to another shared instance type.

Warning

Before you perform the upgrade, we recommend that you purchase a pay-as-you-go or serverless RDS instance that has the required specifications. This way, you can use the new RDS instance to test the compatibility with your workloads. For more information, see Create an ApsaraDB RDS for SQL Server instance.

During the major engine version upgrade, we recommend that you do not modify metadata of your RDS instance. Otherwise, data inconsistency issues may occur after the upgrade. For example, we recommend that you do not create databases, delete databases, or modify the recovery models of databases.

Limits

You cannot upgrade the major engine versions of the following RDS instances:

RDS instances that are added to Active Directory (AD) domains. For more information, see Connect an ApsaraDB RDS for SQL Server instance to a self-managed domain.
RDS instances that use Bring Your Own License (BYOL).
Serverless RDS instances. For more information, see Overview.
RDS instances of the classic network type. For more information, see Change the network type.
Read-only RDS instances and primary RDS instances that have read-only RDS instances and run RDS Cluster Edition. For more information, see Create a read-only ApsaraDB RDS for SQL Server instance.

Impacts

If you start an upgrade task on your RDS instance, you cannot cancel the upgrade task. After the upgrade is complete, your RDS instance cannot be rolled back to the earlier major engine version.
The settings of your RDS instance, such as the instance name, port, tags, and database accounts, remain unchanged after the upgrade.
The period of time that is required to complete the upgrade varies based on the data volume of your RDS instance. For more information, see FAQ.
In most cases, the upgrade requires workload switchover, which may cause your RDS instance to be unavailable for approximately 20 minutes. Make sure that your application is configured to automatically reconnect to your RDS instance. For more information, see FAQ.
The upgrade changes the virtual IP address (VIP) of your RDS instance. We recommend that you use the endpoint of the RDS instance instead of the IP address to connect your application to the instance.
After the upgrade, we recommend that you immediately delete the cached DNS records from the database client. If the database client runs on a Java virtual machine (JVM), we recommend that you set the time-to-live (TTL) in the JVM configuration to 60 seconds or less. This way, if the VIP that is bound to the in-use endpoint of your RDS instance changes, your application can query the related DNS records to obtain the new VIP. Then, your application can connect to the new VIP.
Note
The following TTL-setting methods are provided for reference:
- For all JVM-based applications, set the networkaddress.cache.ttl parameter in the $JAVA_HOME/jre/lib/security/java.security file to 60.
- For local applications, configure the networkaddress.cache.ttl java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); setting in the initialization code of local applications. The configuration must be completed before you call the InetAddress.getByName() function for the first time to establish a network connection.
If your RDS instance has an ongoing Data Transmission Service (DTS) task, you must re-configure and start the DTS task after the upgrade is complete. For more information, see What is DTS?

Billing rules

For more information about the fees for the upgrade, see Specification changes.

Procedure

Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.
In the Configuration Information section of the Basic Information page, click Upgrade Version. In the dialog box that appears, click OK.
Note
If Upgrade Version is not displayed, you must check whether the RDS instance meets the requirements. For more information, see Limits.

On the Upgrade Engine Version page, configure the following parameters. For more information about other parameter settings, see Procedure.

Note

When you upgrade the major engine versions of some RDS instances, some major engine versions and RDS editions may be unavailable. For more information, see the "Usage notes" and "Limits" sections in this topic.

Parameter	Description
Upgrade To	Select the major engine version to which you want to upgrade. The options for the Edition and Instance Type parameters vary based on the value of this parameter. For more information, see Upgrade rules.
Edition	Select the RDS edition to which you want to upgrade. Basic Edition: The database system consists of only a primary RDS instance. Computing is decoupled from storage. High-availability Edition: The database system consists of a primary RDS instance and a secondary RDS instance. These instances work in high availability mode to achieve balanced performance in all aspects. Cluster Edition: The database system consists of a primary RDS instance and multiple secondary RDS instances. These instances work in high availability mode. The secondary RDS instances are accessible. Note For more information about RDS editions, see Overview.
Instance Type	Each instance type supports a specified number of cores, memory capacity, maximum number of connections, and maximum IOPS. For more information, see Primary ApsaraDB RDS instance types.
Switching Time	Switch Immediately After Data Migration: After the migration is complete, workloads are immediately switched over. Switch Within Maintenance Window: After the migration is complete, workloads are switched over during the specified maintenance window.

Read and select Terms of Service and click Pay Now.
In the message that appears, click Agree and Place Order.
The status of the original RDS instance changes to Upgrading/Downgrading > Upgrading Across Networks. If the status of the original RDS instance changes to Running, the upgrade is complete. The time that is required to complete the upgrade varies based on the amount of data.

FAQ

Can I change the configuration such as the instance type of my RDS instance during the major engine version upgrade of the RDS instance?

No, you cannot change the configuration such as the specifications of an RDS instance during the major engine version upgrade of the RDS instance. You can change the configuration only after the major engine version is upgraded.

Can the major engine version of an RDS instance be automatically upgraded?

No, the major engine version of an RDS instance cannot be automatically upgraded.

How long does it take to upgrade the major engine version?

Estimated time

The following table describes the estimated time required to upgrade the major engine version of an instance. The speeds of data backup and restoration are estimated based on the size of uncompressed data.

Note

Backup compression is not supported for RDS instances that run SQL Server Web. This may reduce the speeds of data backup and restoration to less than 100 GB per hour.

Operation	Required	Estimated time	Description
Create and configure an RDS instance	Yes	10 to 15 minutes	The time required varies based on the RDS edition and instance type of the new RDS instance that runs the required major engine version.
Back up full data	Optional	200 GB per hour	If no full backups are performed on the RDS instance within 36 hours, a full backup is performed during the upgrade process to balance the time required for data restoration from incremental transaction log backups and full backups. We recommend that you perform a full backup before the major engine version upgrade or initiate a restoration task within 36 hours after the system completes the full backup. This reduces the total amount of time required for the upgrade. For more information, see Back up an ApsaraDB RDS for SQL Server instance. 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.
Restore a full backup on the destination RDS instance	Yes	200 GB per hour	None.
Back up incremental transaction logs on the source RDS instance	Yes	200 GB per hour	Before and after an incremental log backup, it may require another 2 minutes to perform operations such as backup preparation, closure, and resource allocation.
Apply an incremental transaction log backup file to the destination RDS instance	Yes	200 GB per hour	Before and after an incremental log backup, it may require another 2 minutes to perform operations such as backup consistency verification.
Restore a database	Yes	Within 2 minutes	Resource consumption: Applying an incremental transaction log is a resource-intensive operation. If a large number of transaction logs are generated for an RDS instance that has small specifications, such as 2 CPU cores and 4 GB of memory, the data restoration speeds decreases. Accelerated Database Recovery option: The Accelerated Database Recovery option is supported for RDS instances that run SQL Server 2019 or later. This reduces the time for database restoration. You can evaluate whether to enable the option based on official Microsoft documentation.
Switch workloads to the new RDS instance and migrate network connections	Yes	10 minutes	None.

Example

Test instance: The RDS instance has 4 CPU cores and 8 GB of memory, and the volume of data on the RDS instance is 600 GB.

Time required to create and configure an RDS instance: approximately 12 minutes.
Time required to back up full data: approximately 3 hours. The time required is calculated by using the following calculation: Time required = 600 GB/200 GB per hour = 3 hours.
Time required to restore a full backup on the destination RDS instance: approximately 3 hours. The time required is calculated by using the following calculation: Time required = 600 GB/200 GB per hour = 3 hours.
Time required to back up incremental transaction logs on the source RDS instance: approximately 5 minutes. The time required is calculated by using the following calculation: Time required = 10 GB/200 GB per hour + Time loss of 2 minutes = 5 minutes.
Time required to apply an incremental transaction log backup file to the destination RDS instance: approximately 5 minutes. The time required is calculated by using the following calculation: Time required = 10 GB/200 GB per hour + Time loss of 2 minutes = 5 minutes.
Time required to restore a database: within 2 minutes
Time required to switch workloads to the new RDS instance and migrate network connections: approximately 10 minutes.

In this example, if no full backups are performed on the RDS instance within 36 hours, the total duration is estimated to be approximately 6 hours and 34 minutes. If a full backup is performed on the RDS instance within 36 hours, the duration is estimated to be approximately 3 hours and 34 minutes.

Upgrade suggestions

Maintenance window: We recommend that you upgrade the major engine version during off-peak hours to minimize the impacts on your workloads.
Long-running transactions: During the upgrade, we recommend that you do not perform long-running transactions, such as creating or rebuilding indexes and archiving data. This helps prevents the time that is required to restore a database from being prolonged.

How do I configure the switching time when I upgrade the major engine version of an RDS instance across time zones?

Scenario: You reside in the UAE (Dubai) region and use India Standard Time (IST, UTC+5:30) for an RDS instance that resides in the Singapore region. Your time zone is Gulf Standard Time (GST, UTC+4). In this case, it is important to determine the switching time when you upgrade the major engine version of the RDS instance to avoid service interruptions.
Purpose: You plan to perform an upgrade at 02:00 on May 11, 2024, UTC+5:30.
Solution: Convert times zones. The time zone of the RDS instance is UTC+5:30. Your time zone is UTC+4, which is also the time zone of your browser. You do not need to consider the region in which the RDS instance resides. In the example, May 11, 2024, 02:00 UTC+5:30 can be converted to May 11, 2024, 00:30 UTC+4. You must log on to the ApsaraDB RDS console and configure the switching time of the RDS instance at 00:30 on May 11, 2024.
The following list describes how to convert time zones:
1. Convert the IST time May 11, 2024, 02:00 to the Coordinated Universal Time (UTC) time. IST is 5 hours and 30 minutes ahead of UTC. Therefore, the result is May 10, 2024, 20:30 UTC.
2. Convert the UTC time May 10, 2024, 20:30 to the GST time. UTC is 4 hours behind GST. Therefore, the result is May 11, 2024, 00:30, GST.

Reference

You can also upgrade the major engine version by using API. For more information, see ModifyDBInstanceSpec.