PolarDB:Serverless feature for fixed-specification clusters

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.

Configure current parameters

In the Configure Serverless-related Parameters dialog box, click Edit to set the parameters.

• Current Parameters

  • Minimum Read-only Nodes: The minimum number of additional read-only nodes. Valid values: 0 to 15.

  • Maximum Read-only Nodes: The maximum number of additional read-only nodes. Valid values: 0 to 15.

  Note

  The system automatically increases or decreases the number of read-only nodes based on the workload, within the specified limits. For more information, see Scaling.

  • Minimum Resources for Single Node: The minimum number of PCUs for each node in the cluster. Valid values: 0 PCU to 16 PCU.

  • Maximum Resources for Single Node: The maximum number of PCUs for each node in the cluster. Valid values: 0 PCU to 16 PCU.

  Note

  Example: If you set Minimum Resources for Single Node to 2 PCU and Maximum Resources for Single Node to 8 PCU, each node gains a serverless capacity that scales between 2 and 8 PCU on top of its fixed specifications. The node's baseline becomes its fixed specifications plus 2 PCU (about 2 cores, 4 GB of memory). As the workload increases, the system adds capacity up to a maximum of 8 PCU. The final specifications cannot exceed the fixed specifications plus 8 PCU (about 8 cores, 16 GB of memory).

  • Number of read-only column store nodes: The number of read-only column store nodes. Valid values: 0 to 15.

    Note

    • This parameter is displayed and can be configured only if your fixed-specification cluster already has read-only column store nodes.

    • For more information about read-only column store nodes, see IMCI (In-Memory Column Index).

• Advanced Settings

  You can adjust the advanced parameters based on the resource pressure on your serverless cluster.

  • Scan Interval: This setting determines how quickly the cluster responds to workload changes. Select Standard or Sensitive.

  • Maximum CPU Resources for Elastic Upgrade (Maximum): The CPU utilization threshold that triggers a scale-up action. The value can range from 40% to 100%.

  • Minimum CPU Resources for Elastic Upgrade (Minimum): The CPU utilization threshold that triggers a scale-down action. The value can range from 10% to 70%.

  Note

  • The CPU scale-down threshold must be lower than the CPU scale-up threshold. The difference between the two thresholds must be at least 30 percentage points.

  • Sensitive mode is suitable for workloads that are sensitive to transient load fluctuations (for example, short CPU spikes) and need a faster response. However, the cluster may scale up and down more frequently as the load changes.

Create a lifecycle policy

A lifecycle policy scales cluster resources on a predefined schedule (daily, weekly, or monthly). You can use it to scale up resources for predictable peak periods, such as promotional events, and scale them down during off-peak hours to reduce costs.

1. In the Configure Serverless-related Parameters dialog box, click + Add Lifecycle Policy. The following table describes the parameters.

   Parameter	Value
   Maximum Resources for Single Node	0 to 16 PCU.
   Minimum Resources for Single Node	0 to 16 PCU. The value must be less than or equal to the value of Maximum resources for a single node.
   Maximum Read-only Nodes	0 to 15.
   Minimum Read-only Nodes	0 to 15. The value cannot be greater than the value of Maximum Read-only Nodes.
   Number of read-only column store nodes	0 to 15. Note This parameter is displayed and can be configured only if your fixed-specification cluster already has read-only column store nodes. For more information about read-only column store nodes, see IMCI (In-Memory Column Index).
   Start/End Time	The effective time range for the lifecycle policy.
   Policy scheduling	The schedule for the lifecycle policy. Monthly: Select specific days of the month and a specific time for execution. You can count from the Positive or the Last of the month. To specify multiple days, separate the numbers with commas (,), for example, 1,3,5. Weekly: Select specific days of the week (Monday to Sunday) and a specific time for execution. Daily: Select a specific time for daily execution.

   Note

   After you configure a lifecycle policy, the system adjusts the cluster's Serverless configuration parameters at the scheduled time of the lifecycle policy within the specified Start/End Time. After the adjustment is complete, the cluster's Serverless configuration parameters do not automatically revert. To restore the original configuration parameters at a specific time, you must configure a separate lifecycle policy. For a detailed example, see Example.

2. (Optional) View the execution plan. You can use one of the following methods:

   Note

   A lifecycle policy generates scheduled tasks. When you create a policy, the system creates the corresponding tasks based on its schedule.

   • After you create a lifecycle policy, you can view it on the cluster details page.

     On the cluster details page, you can view the resulting scheduled tasks in the Pending execution plan and failed retry tasks section. This section displays information such as the task ID, task status (Pending), task action (for example, ModifyDBClusterServerlessConf), and scheduled start time. You can also perform actions such as Cancel or Modify Scheduled Time.

   • Go to Task Management > Scheduled Tasks in the console.

     On this page, you can view the Task Status, such as Pending or Canceled. For pending tasks, you can click Cancel in the Actions column to cancel them.