The features that are provided by different SQL Server versions on 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.
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.
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.
WarningThe upgrade operations cannot be rolled back. Before you perform an upgrade, we recommend that you purchase a pay-as-you-go RDS instance that has the required specifications to test the compatibility with your workloads. For more information, see Create an ApsaraDB RDS for SQL Server instance.
After the upgrade is complete, you must switch over your workloads. The downtime caused by the switchover varies based on the data volume of your RDS instance. In most cases, the switchover requires approximately 20 minutes. We recommend that you switch over your workloads during the specified maintenance window. Make sure that your application is configured to automatically reconnect to your RDS 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 for which the Transparent Data Encryption (TDE), SSL encryption, or cloud disk encryption feature is enabled. For more information, see Configure TDE for an ApsaraDB RDS for SQL Server instance, Configure SSL encryption for an ApsaraDB RDS for SQL Server instance, or Configure the cloud disk encryption feature for an ApsaraDB RDS for SQL Server instance.
RDS instances of the classic network type. For more information, see Change the network type of an ApsaraDB RDS for SQL Server instance.
RDS instances for which the snapshot backup feature is enabled. For more information, see Enable the snapshot backup feature for an ApsaraDB RDS for SQL Server instance.
Read-only RDS instances and primary RDS instances on RDS Cluster Edition to which read-only RDS instances are attached. 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. In most cases, the upgrade requires approximately 20 minutes to complete. If a large number of operations are performed during the upgrade, the period of time to complete the upgrade is prolonged. We recommend that you upgrade your RDS instance during an appropriate period of time.
The upgrade may cause your RDS instance to be unavailable for a short period of time. Make sure that your application is configured to automatically reconnect to your RDS instance.
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.
NoteThe 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 theInetAddress.getByName()
function for the first time to establish a network connection.
If your RDS instance is attached to a PolarDB-X instance, the VIP change temporarily affects the availability of the PolarDB-X instance. We recommend that you refresh the page to view the connection information in the PolarDB-X console at the earliest opportunity.
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 message that appears, click OK.
NoteIf Upgrade Database is not displayed, you must check whether the major engine version of 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 Create an ApsaraDB RDS for SQL Server instance.
Parameter
Description
Upgrade To
Select the database 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.
NoteFor more information about RDS editions, see Overview.
Instance Type
Each instance type supports a specific number of CPU 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 Subscribe.
The status of the original RDS instance changes to
. 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.