Adjust the FE configuration
Scale FE nodes vertically (change the specification) or horizontally (add or remove nodes) to improve your instance's metadata processing, connection throughput, and availability.
Impact
-
Horizontal scale-in and vertical downgrade may result in momentary connection interruptions. Proceed with caution during low-traffic periods, and make sure your application implements a reconnection mechanism beforehand.
Scaling type
Business impact
Horizontal scale-out
No impact
Horizontal scale-in
Brief connection drops
Vertical upgrade
Connection drops for approximately 30 seconds to 1 minute
Vertical downgrade
Connection drops for approximately 30 seconds to 1 minute
-
Management operations: During the configuration change, the instance enters the Changing Specifications state, and management operations (restart, upgrade, and configuration change) are unavailable.
Limits
For instances with the legacy FE deployment mode (master-observer), you can only add Observer nodes when scaling out. Adding Observer nodes to instances running version 3.0 may temporarily reduce cache hit rates. We recommend performing this operation during off-peak hours.
The FE deployment mode is legacy (master-observer) if the FE has 2 nodes or the kernel version is earlier than 4.0.4. Otherwise, it is the upgraded mode (follower).
Specifications
-
Node specification: 4 CU to 64 CU
-
Node count: 1 to 11 (odd numbers)
Costs
You can estimate the additional FE charges starting from August 15 based on the FeSize and billing rules. For subscription instances, the FE charges for the current subscription period are added in the first renewal cycle after August 15.
FE downgrade guide
To reduce FE specifications and control costs, we recommend reviewing the FE CPU and JVM memory metrics over the past 7 days, including peak business hours. Lower the specification by one tier at a time, and monitor for at least 7 days before further adjustments.
Consider lowering the specification by one tier when all FE nodes meet the following conditions:
|
Metric |
Downgrade condition |
|
CPU utilization |
Average utilization below 20%, peak below 40%. |
|
JVM memory |
Clear drop after GC, with minimum watermark consistently below 30%. |
|
Full GC |
No frequent Full GC, and JVM memory minimum watermark is not trending upward. |
Recommended configuration
For production environments, we recommend keeping at least 4-core × 3 voting nodes to balance baseline processing capacity and high availability:
-
4 cores provide the necessary resource headroom for SQL parsing, query planning, metadata management, and background tasks.
-
3 voting nodes form a majority quorum, so if any 1 node fails, the remaining 2 can continue serving traffic.
-
A single node offers no high availability. Even-numbered voting nodes generally do not improve failover capacity.
FE voting nodes typically use odd numbers such as 1, 3, or 5. Non-voting nodes such as Observers are not counted toward the quorum.
Adjust the configuration
-
Go to the ApsaraDB for SelectDB console.
-
On the Instances page, find the instance you want to adjust.
-
In the Actions column, click More, and then choose an action based on your needs:
-
To add FE nodes, click FE horizontal expansion.
-
To remove FE nodes, click FE Scale In.
-
To upgrade the FE node specifications, click FE Scale Up.
-
To downgrade the FE node specifications, click FE Scale Down.
NoteFE nodes must be in odd numbers, with a minimum of 1. Removing nodes may cause brief connection drops. We recommend performing this operation during off-peak hours.
-
-
Verify the current configuration, then select the target specification (Core) or node count in the configuration parameters section.
-
The bottom of the page shows the updated FeSize and price in real time. Accept the service agreement, and click Buy now.
-
Return to the Instances page. The change takes effect once the instance status returns to Running.