All Products
Search
Document Center

ApsaraDB RDS:Upgrade the major engine version

Last Updated:Feb 21, 2024

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 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:

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 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

  1. 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.
  2. In the Configuration Information section of the Basic Information page, click Upgrade Version. In the message that appears, click OK.

    Note

    If 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.

    image.png

  3. 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.

    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 specific 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.

  4. Read and select Terms of Service and click Pay Now.

  5. In the message that appears, click Subscribe.

    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 an 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 much time is required 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 product type and instance type of the new RDS instance that is used for the major engine version upgrade.

Back up full data

No

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 manually perform a full backup before the major engine version upgrade or initiate a restoration task within 36 hours after the system automatically 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, a time loss of 2 minutes may occur. The time loss may be caused by 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 file is applied, a time loss of 2 minutes may occur. The time loss may be caused by 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.