ApsaraDB RDS:Change the instance billing method from serverless to pay-as-you-go

Prerequisites

The RDS for SQL Server instance must meet the following requirements:

• Edition: High-availability Edition

• Billing method: Serverless

• Instance state: Running

Usage notes

The number of CPU cores included in the instance type of the pay-as-you-go instance must be equal to or larger than the RCU upper limit of the current serverless instance.

Limitations

• You can change the billing method of an instance from serverless to pay-as-you-go only once every 24 hours.

• You can change the billing method only to a shared instance type. If you require other instance types, first follow the instructions in this topic to change to a shared instance type. Then, change the instance type as required.

Impacts

• The change of the billing method from serverless to pay-as-you-go is implemented based on data migration at the underlying layer. The process includes steps such as creating a new instance, full backup, incremental log synchronization, restoration, and network switchover. The change process causes a temporary disconnection that lasts less than 20 minutes. Make sure that your application is configured to automatically reconnect to the instance.

  Estimated duration for changing the billing method from serverless to pay-as-you-go

  The following table describes the estimated duration of each step. Note that the backup and restoration speeds are based on size of uncompressed data.

  Step	Required	Estimated duration	Notes
  Create and configure the new instance	Yes	10 to 15 minutes	The required time varies based on the edition and instance type that you select.
  Perform a full backup on the instance	No	200 GB/hour	Based on the full backup policy, if no full backup has been performed on the instance within the last 36 hours, a full backup is performed during the major version upgrade to balance the time required for transaction logs and full backups. We recommend that you back up your RDS for SQL Server instance at a suitable time before the major version upgrade. Alternatively, you can initiate the major version upgrade task within 36 hours after the system-initiated full backup is complete. This reduces the total time required for the upgrade. The backup speed may vary based on the region and time period. To obtain more accurate backup and restoration performance metrics, refer to the data volume and time of the last full backup.
  Restore the full backup to the destination instance	Yes	200 GB/hour	None
  Perform an incremental transaction log backup on the source instance	Yes	200 GB/hour	An additional 2 minutes may be required before and after the incremental log backup for operations such as backup preparation, finalization, and resource allocation.
  Apply the incremental transaction log backup to the destination instance	Yes	200 GB/hour	An additional 2 minutes may be required before and after applying the incremental log backup for operations such as backup consistency verification.
  Bring the database online	Yes	Typically within 2 minutes	Resource consumption:Applying incremental transaction logs is a resource-intensive operation. For instances with low specifications (for example, 2 CPU cores and 4 GB of memory), the recovery speed may be reduced due to a large number of transaction logs. Accelerated Database Recovery option: RDS instance running SQL Server 2019 and later provides Accelerated Database Recovery, which may reduce the time required to bring the database online. For more information about whether to enable this option, see the official Microsoft documentation.
  Wait for network switchover and migrate network connections	Yes	10 minutes	None

• The virtual IP (VIP) address of the instance changes during the billing method change. To ensure business continuity, you must use the internal or public endpoint of the RDS instance to connect to your application instead of the resolved IP address. The endpoint of an RDS instance is a dynamic domain name that provides automatic routing and can seamlessly adapt to backend IP address changes.

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

Billing

The feature that allows you to change the billing method from serverless to pay-as-you-go is free of charge. For more information about the billing of pay-as-you-go instances, see Billing overview.

Procedure

1. Go to the Instances page. In the top navigation bar, select the region of the instance. Then, click the instance ID.

2. On the Basic Information page, in the Configuration Information section, click Convert tto Pay-As-You-Go.

3. On the RDS buy page, configure the Instance Type and Switching Time parameters.

4. Click Confirm Order. In the dialog box that appears, confirm the instance configurations before and after the change, and then click OK to complete the payment.

   Note

   During the change, the state of the instance changes to Changing Configuration. After the change is complete, the state of the instance changes to Running.

FAQ

Q: After I change the billing method of an instance from serverless to pay-as-you-go, why is the order type displayed as New Purchase on the Orders page in the Expenses and Costs console?

A: The billing method change is implemented by purchasing a new pay-as-you-go instance and then switching your workloads over from the origin instance to the new instance. Therefore, the order is displayed as a new purchase.

Related operation

You call the API operation (ModifyDInstanceSpec) to change the billing method from serverless to pay-as-you-go. Take note of the following items when you call this operation:

• Make sure that the original billing method of the instance is Serverless and set the PayType parameter to Postpaid.

• Set the DBInstanceClass parameter to the destination instance type. For more information, see Instance types for primary ApsaraDB RDS for SQL Server instances.

• Leave other parameters, such as the storage capacity, empty or keep their original values. You cannot modify these parameters during the change.