ApsaraDB RDS:Change Serverless to pay-as-you-go

Prerequisites

Your ApsaraDB RDS for SQL Server instance must meet the following requirements:

• Edition: High-availability Edition

• Billing method: Serverless

• Instance state: Running

Considerations

When you select an instance type, we recommend that the vCore count be equal to or greater than the current RCU upper limit. For example, if the original instance has an RCU upper limit of 4, select an instance type with 4 or more vCores.

Limitations

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

• You can only convert your instance to a shared instance type. If you need a different instance type, first convert the instance to a shared instance type as described in this topic. Then, you can change the instance configuration to a different instance type.

Impacts

• This conversion requires an underlying data migration, which involves creating a new instance, performing a full backup, synchronizing incremental logs, restoring data, and performing a network switchover. Downtime is typically less than 20 minutes. Ensure your application has an auto-reconnect capability.

  Estimated duration for converting a Serverless instance to a pay-as-you-go instance

  The following table lists the estimated duration of each stage. Backup and restore speeds are based on uncompressed data sizes.

  Operation	Required	Estimated duration	Notes
  Create and configure the new instance	Yes	10 to 15 minutes	The duration depends on the product edition and instance type that you select.
  Perform a full backup of the instance	Conditional	200 GB/hour	Based on the full backup policy, if a full backup has not been performed on the instance in the last 36 hours, a full backup is performed during the conversion. This helps balance the time required for full backup restoration and transaction log replay. To reduce the conversion time, we recommend that you back up SQL Server data at a suitable time before the conversion. Alternatively, start the conversion within 36 hours after an automatic full backup is completed. The backup speed can vary based on the region and time of day. To obtain a more accurate estimate of backup and restore performance, refer to the data volume and duration of your last full backup.
  Restore the full backup on the destination instance	Yes	200 GB/hour	None
  Back up incremental transaction logs on the source instance	Yes	200 GB/hour	An additional 2 minutes may be required before and after the incremental log backup for tasks such as preparation, finalization, and resource allocation.
  Apply incremental transaction log backups on the destination instance	Yes	200 GB/hour	An additional 2 minutes may be required before and after the log backups are applied for tasks 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 a small instance type, such as 2 vCores and 4 GB of memory, the recovery speed may decrease if a large number of transaction logs exist. Accelerated Database Recovery: ApsaraDB RDS for SQL Server 2019 and later versions provide the Accelerated Database Recovery feature, which can reduce the time to bring the database online. For details, see the official Microsoft documentation.
  Network switchover and connection migration	Yes	10 minutes	None

• The virtual IP address (VIP) changes during the conversion because the underlying resources are migrated. To ensure service stability and continuity, you must use the internal endpoint or public endpoint of the RDS instance in your application instead of a hardcoded IP address. The endpoint is a dynamic domain name that automatically routes traffic to the updated backend IP address.

• Clear the DNS cache on your client. If your client is a JVM-based application, we recommend setting the TTL in the JVM configuration to 60 seconds or less. This ensures that when the VIP address of the endpoint changes, the application can obtain the new VIP address by re-querying the DNS.

  Note

  The following methods for setting the TTL in the JVM are for your reference:

  • To set the TTL for all JVM-based applications, set the networkaddress.cache.ttl parameter in the $JAVA_HOME/jre/lib/security/java.security file to 60.

  • To set the TTL for only a local application, set java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); in the application's initialization code before any network connections are established, specifically before the first call to InetAddress.getByName().

Billing

The conversion from Serverless to pay-as-you-go is free of charge. For more information about how pay-as-you-go instances are billed, see Billing overview.

Procedure

1. Go to the ApsaraDB RDS Instances page. In the upper-left corner, select the region where your instance is located, and then click the ID of the instance.

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

3. On the purchase page, configure theInstance Type and Switching Time parameters.

4. Click Pay Now. Confirm the configuration details before and after the change, click OK, and complete the payment.

   Note

   During the conversion, the instance state changes to Upgrading/Downgrading. After the conversion is complete, the instance state changes to Running.

FAQ

Q: After you convert a Serverless instance to pay-as-you-go, why is the order type displayed as New Purchase in Expenses and Costs > Order Management?

A: The conversion provisions a new pay-as-you-go instance and migrates data from the original instance, so the order is recorded as a New Purchase.

Related operations

If you use the ModifyDBInstanceSpec operation to change the billing method from Serverless to pay-as-you-go, note the following:

• Ensure the instance's original billing method is Serverless and set the PayType parameter to Postpaid.

• Set the DBInstanceClass parameter to the target instance type. For a list of supported instance types, see Primary ApsaraDB RDS for SQL Server instance types.

• Leave other parameters, such as storage capacity, unchanged. They cannot be modified during the conversion.