DocsICP FilingConsole
Documentation
Home Page PolarDB PolarDB for MySQL User Guide Serverless Serverless FAQ

Serverless FAQ

Updated at:
Copy as MD
Product
My Favorites

This topic provides answers to frequently asked questions about serverless clusters.

PolarDB serverless FAQ

Key concepts

PolarDB serverless types

PolarDB serverless is available in the following two types:

  • Agile serverless (serverless cluster): The cluster specifications dynamically scale up or down within a defined range based on the workload. This type is ideal for scenarios with highly volatile workloads. For more information, sCreate a serverless clusteree .

  • Stable serverless (serverless enabled on defined-specification nodes): The defined-specification portion of resources never scales down, ensuring business stability. The serverless portion can scale up or down in seconds based on the workload. This type is ideal for scenarios with relatively stable workloads that experience occasional spikes. For more information, sEnable serverless for fixed-specification clustersee .

What is PCU in a serverless cluster?

PCU is short for PolarDB Unit. Capacity1 PCU is equivalent to the standard service capacity of approximately 1 core and 2 GB of memory.PolarDB PCU is the resource scaling unit for serverless clusters, and the minimum unit for a single scaling operation is 0.5 PCU.

What is the maximum storage capacity of a PolarDB serverless cluster?

The maximum storage capacity of a serverless cluster is 500 TB.

Does a PolarDB serverless cluster support a hot standby cluster?

Yes. You can enable a hot standby cluster when you create a PolarDB serverless cluster.

Purchase and use

How much can I save with a serverless cluster compared to a regular cluster?

To estimate how much you can save by switching from a non-serverless cluster to a serverless cluster, click View on the Serverless option of the bCost assessment tooluy page.

You are also welcome to try serverless elasticity for free.

How are PolarDB serverless clusters billed?

Serverless clusters are billed by the second. Each billing cycle is based on the average PCU usage during that period. For more information, sBillingee .

Are there cost-saving options for compute and storage fees of PolarDB serverless clusters?

The compute resources of serverless clusters can be offset by serverless compute plans, and the storage capacity can be offset by storage plans. For more information, sBillingee .

Elastic scaling

What is the elastic range of PolarDB serverless?

The maximum scaling range allowed for a single node (RW or RO node) is 1 to 32 PCUs (approximately 32 cores and 64 GB). A cluster can have up to 15 additional RO nodes. Therefore, the theoretical maximum compute specifications of the entire cluster are 32 × 16 = 512 PCUs. The scaling range per node and the number of RO noConfigure auto scaling for a serverless clusterdes

How long does scaling take for a PolarDB serverless cluster?

The local scaling time for a single node in a serverless cluster is within 10 seconds (cross-machine scaling time is within 30 seconds). The scaling time consists of three parts: Detection time + decision time + execution time, where the detection time is 5 seconds, and the decision and execution times are each within 1 second. When a single node in the serverless cluster reaches the configured upper limit (for example, the configured scaling range per node is 1 to 16 PCUs, the RW node reaches the upper limit of 16 PCUs), and the current workload still exceeds the processing capacity of the cluster, the serverless cluster automatically adds RO nodes (the number of RO nodes does not exceed the user configuration). The time to add an RO node is about 1 minute. When the workload decreases and an RO node is idle, the RO node is reclaimed and deleted. To avoid frequent adding and deleting of RO nodes under periodic workloads, the decision time for deleting an RO node is in minutes.

What metrics trigger scale-up for a PolarDB serverless cluster?

Scale-up and scale-out triggers

  • Vertical scaling (scale-up)

    PolarDB monitors the CPU utilization, memory usage, and other kernel-level metrics of the primary and read-only nodes. During a monitoring period, the system typically triggers a scale-up for a node when any of the following conditions is met:

    • The CPU utilization is higher than the preset threshold (default: 80%).

    • The memory usage is higher than a specific threshold:

      Serverless format

      Scale-up threshold

      Serverless cluster

      90%

      Serverless feature for clusters with defined specifications

      Less than or equal to 32 GB

      90%

      64 GB

      92%

      128 GB

      96%

      256 GB to 512 GB

      98%

      Other memory specifications

      Vertical scaling is not supported.

    • A read-only node's specifications are less than half of the primary node's.

      For example, if a read-only node has specifications of 4 PCU and the primary node has specifications of 10 PCU, the read-only node is scaled up to at least 5 PCU.

  • Horizontal scaling (scale-out)

    If a read-only node in a cluster has scaled up to its configured maximum limit and still meets the scale-up trigger conditions (for example, its CPU utilization exceeds the custom threshold), a horizontal scale-out is triggered.

Scale-down and scale-in triggers

  • Vertical scaling (scale-down)

    A scale-down is triggered for a node when its CPU utilization falls below the custom threshold (default: 50%) and its memory usage is below a specific threshold. The memory usage thresholds are as follows:

    Serverless format

    Scale-down threshold

    Serverless cluster

    80%

    Serverless feature for clusters with defined specifications

    Less than or equal to 32 GB

    80%

    64 GB

    86%

    128 GB

    90%

    256 GB to 512 GB

    94%

    Other memory specifications

    Vertical scaling is not supported, so no scale-down threshold applies.

  • Horizontal scaling (scale-in)

    A scale-in is triggered for a read-only node if its CPU utilization remains below 15% and the CPU utilization of all other read-only nodes remains below 60% for a sustained period of 15 to 30 minutes.

    Note

    • To prevent node jitter, only one read-only node is scaled in at a time. The cooldown period between consecutive scale-in events is 15 to 30 minutes.

    • To immediately scale in all read-only nodes, modify the Serverless Configuration. Setting both the Maximum Number of Read-only Nodes and Minimum Number of Read-only Nodes to 0 immediately triggers a scale-in of all read-only nodes.

Do the maximum number of connections and maximum IOPS of a serverless cluster change with scale-up?

What does it mean that a larger PCU of a PolarDB serverless cluster results in a larger scaling step?

When the workload of a serverless cluster spikes suddenly, the nodes do not scale up to the target specifications in one step. Instead, they scale up incrementally in small steps. The minimum step for a single scaling operation is 0.5 PCU. To adapt to the current traffic more quickly, the serverless cluster

Why is the memory usage 100% at 1 PCU for a PolarDB serverless cluster?

This is because the maximum specifications for a single node in a serverless cluster are 32 PCUs. Some kernel modules reserve memory to enable fast scale-up from 1 PCU. As aPolarDB result, the console monitoring displays 100% memory usage at 1 PCU.

Can the upper and lower limits of PCU resources for a single node be set to the same value?

Yes. If you set the upper and lower limits of PCU resources for a single node to the same value, the serverless cluster does not scale in response to workload spikes. This may impair your business. We recommend that you properly configure the scaling range of PCU resources for a single node.

Why does a serverless cluster not automatically scale in (release) a read-only node that was scaled out but has a low workload?

The scale-in (node removal) trigger condition is: when the CPU utilization of a read-only node in the cluster is lower than 15% and the CPU utilization of the remaining read-only nodes is lower than 60% for 15 to 30 minutes, the node is scaled in.

Note

  • To prevent node jitter, only one read-only node is scaled in at a time, and the cooldown period for consecutive node scale-ins is 15 to 30 minutes.

  • To immediately scale in all read-only nodes, modify Serverless Configuration. Set Minimum Read-only Nodes to 0. All read-only nodes are immediately scaled in.

Cross-machine scale-up

If local scaling resources are insufficient and scale-up cannot continue, the cross-machine scale-up mechanism is triggered and the cluster is migrated to a machine with more resources. Cross-machine scale-up is enabled by default. To disable it, go to the console and Serverless Configuration > Advanced Settingsnavigate to , then confRW Node Cross-Host ElasticityiguRemote RO Scalingre , or AP RO Remote Scaling

  • RW Node Cross-Host Elasticity and Remote RO Scaling: both support selecting On, Disable or During Maintenance Window (for maintenance window details, see Configure a maintenance window)..

  • AP RO Remote Scaling configuration is displayed in the console only when the cluster has a columnar index reaAP RO Remote Scalingd-only node. For performance reasons, the AP RO node only supports selecting or Disable. IDuring Maintenance Windowt does not supOnport .

Note

The statement that cross-machine scale-up is enabled by default applies only to and ,RW Node Cross-Host Elasticity whicRemote RO Scalingh are enabled by default. It does not mean AP RO Remote Scalingthat is enabled. must be configured separately.

Business impact

Compute node migration is typically completed within 5 to 10 minutes.

  • During the migration of the primary node (read/write node), one to two transient interruptions of 30 to 90 seconds may occur. If the cluster has enabled anFailover with hot replicad Binlog is not enabled, the migration of the primary node (read/write node) is virtually interruption-free.

  • During the migration of read-only nodes, write operations are not affected.

Other

What is strong transaction consistency in a PolarDB serverless cluster?

Strong transaction consistency ensures that read transactions on RO nodes are coordinated with the RW node, so that data read from RO nodes conforms to the ACID properties of the entire cluster.

  • In a defined-specification cluster, the number of RO nodes is fixed. You can configure an appropriate consistency policy based on the topology corresponding to the cluster endpoint.

  • In a serverless cluster, by default only one RW node exists, and RO nodes automatically scale in and out based on the workload. Whether read/write splitting occurs cannot be predicted. Therefore, we recommend that you always configuGlobal consistency (high-performance mode)re .

How do I migrate a regular PolarDB cluster to a serverless cluster?

To migratPolarDBe a regular PolarDB cluster to a serverless cluster, use DTS.

Can a regular PolarDB cluster (subscription or pay-as-you-go) be upgraded to a serverless cluster?

Yes. You can enable the serverless feature on a regular PolarDB cluster (subscription or pay-as-you-go), that is, enable the serverless feature for a defined-specification cluster. For more information, seEnable serverless for fixed-specification clusterse .

PolarDB for MySQLDoes enabling the serverless feature for a defined-specification cluster cause transient interruptions?

When you enable the serverless feature on a defined-specification cluster, if the current host resources are insufficient, the cluster may be migrated (to an idle host) with a certain probability. Therefore, we recommend that you enable the serverless feature during off-peak hours. For more information, sServerless feature for fixed-specification clustersee .

Note

  • If you use the primary endpoint to connect to the database, transient interruptions of 5 to 10 seconds may occur during cluster migration.

  • If you use the cluster endpoint to connect to the database, no transient interruptions occur during cluster migration. We recommend that you use the cluster endpoint to connect to the database and make sure that the hitless failover feature is in effect. For more information, see Connecting to a PolarDB Cluster and Failover with hot replica.

Serverless compute plan FAQ

Purchase and use

What fees can a serverless compute plan offset?

Serverless compute plans can be used to offset thePolarDB compute resource fees of serverless clusters and the compute resource fees of scaling operations enabled by the serverless feature on defined-specification clusters.

How do I use a serverless compute plan?

  • If you have alPolarDBready purchased a serverless cluster, you can directly purchase a serverless compute plan to offset the compute resource fees in the cluster.

  • If you have alrPolarDBeady purchased a defined-specification cluster with the serverless feature enabled, you can directly purchase a serverless compute plan to offset the compute resource fees for scaling operations in the cluster.

Note

If you have not purchased any serverless cluster or the current cluster has not enabled the serverless feature, you can quickly use a serverless compute plan in just two steps:

  1. Purchase and view serverless compute plans

  2. Create a serverless clusterorEnable serverless for fixed-specification clusters

Is a serverless compute plan required after I purchase a serverless cluster?

No. You can decide whether to purchase a serverless compute plan as needed. After purchase, the plan automatically offsets the compute resource fees in the serverless cluster.

ServerlessDoes the compute plan support vouchers?

You can check the scope of your voucher to confirm whether it supports serverless compute plans. If your voucher scope includes serverless compute plans but you cannot offset the payment when purchasing one, contact Alibaba Cloud technical support for assistance.

Is a serverless compute plan sufficient to offset all fees of a serverless cluster?

No. In a serverless cluster, the serverless compute plan can only offset compute resource fees. Data storage must be paid separately and is billed by default based on usage. You can also rePurchase a storage planduce overall storage fees.

Do serverless clusters support TDE?

Yes. Serverless clusters support the fTDE encryptioneature.

Supported clusters

allPolarDB clusters can use serverless compute plans?

PolarDB Both serverless clusters and defined-specification clusters with the serverless feature enabled can use serverless compute plans.

that were created before the serverless compute plan was purchasedPolarDB serverless clusters also support the use of serverless compute plans?

Yes.

that had the serverless feature enabled before the serverless compute plan was purchasedPolarDBDo defined-specification clusters also support serverless compute plans?

Yes.

Can a serverless compute plan be used by multiplePolarDB clusters for shared offset?

Yes.

Can I specify a cluster to useServerless compute plan offset?

Specifying a cluster to use a serverless compute plan is not supported.

Offset targets

Can a serverless compute plan offset all fees of a pay-as-you-go cluster?

No. When you PolarDBuse a cluster, you need to pay for compute nodes, storage space, data backups (only charged when the free quota is exceeded), SQL Explorer (optional), and GDN (optional).

After you purchase a serverless compute plan, the compute nodes in the serverless cluster are no longer billed hourly. Instead, the fees are offset from the serverless compute plan based on PCU usage. However, other fees cannot be offset by the serverless compute plan.

How is the offset fee of a serverless compute plan calculated?

A serverless compute plan offsets the PCU usage of all nodes in the cluster on an hourly basis. The specific calculation rules are as follows:

  • Within one hour, each time the PCU count changes, the serverless compute plan offsets once.

  • Offset coefficient per offset = offset factor × time coefficient. The time coefficient = the number of seconds this PCU lasts / 3600 (the number of seconds in one hour).

  • The sum of offset coefficients within each hour equals the offset factor for the corresponding region.

a 100,000-PCUServerless compute plan aboutHow long can the offset last?

The following example uses a serverless cluster with 1 primary node and 2 read-only nodePolarDB for MySQLs, all configured with 1 to 32 PCUs:

  • Assume that from 9:00 to 19:00, the primary node runs stably at 4 PCUs and both read-only nodes run at 2 PCUs. From 19:00 to 9:00 the next day, the primary node runs stably at 2 PCUs and both read-only nodes run at 1 PCU. The 24-hour consumption is approximately: (4+2+2) × 10h +

  • Assume that the cluster runs with the primary node at 4 PCUs and both read-only nodes at 2 PCUs throughout the day, except for a half-hour peak from 12:00 to 12:30 when the primary node scales up to 10 PCUs and both read-only nodes scale up to 8 PCUs. The 24-hour consumption is approximately (4+2+2) × 23.5h

Upgrade and renewal

Can I upgrade a serverless compute plan?

No. If the serverless compute plan capacity is insufficient, you can purchase additional serverless compute plans to stack. After purchasing multiple serverless compute plans, offsets are applied in the order of the serverless compute plan purchase times.

Can I renew a serverless compute plan?

No. Each serverless compute plan is valid for 1 year, 3 years, or 5 years. Any remaining capacity automatically expires when the validity period ends. If your serverless compute plan is about to expire or has expired, you can purchase additional plans to stack.

Other

Why can't I see the offset information in the Expenses console forServerless compute plan?

A serverless compute plan takes effect immediately after purchase. However, specific offset information is typically delayed by 6 hours. We recommend that you wait a while before checking. For more information, sView the offset usage of a serverless compute planee .

How to unsubscribe serverless compute plan?

You can unsubscribe from the serverless compute plan in the console. For more information, seUnsubscribe from a serverless compute plane .

Previous：Serverless scalabilityNext：Purchase a cluster