Use Cases
For a TencentDB for MongoDB instance with a fixed specification, the number of CPU cores cannot be dynamically adjusted after creation, making it less flexible in handling sudden or temporary traffic. The CPU elastic scale-out feature allows you to temporarily increase the number of CPU cores beyond the instance's original specification and then scale them back to the original specification after the operation ends, helping you:
Quickly handle traffic peaks: Manually increase the number of cores when a business peak arrives to alleviate performance pressure caused by sudden requests. The scale-up takes effect immediately, faster than a regular configuration change, and the cores are scaled back after the peak ends.
Pay-as-you-go: The additional CPU cores from the scale-up are billed based on actual usage duration. This eliminates the need to reserve high-specification resources long-term to handle traffic peaks, thereby avoiding resource idleness and cost waste.
Feature Description
CPU elastic scale-up currently supports the custom scale-up (immediate effect) mode: You manually enable the scale-up and specify the number of additional cores. After enabling, the number of cores is immediately increased based on the original specification, and after you manually disable it, the cores are scaled back to the original specification.
How It Works
Scale-Up and Scale-Down
CPU elastic scale-out temporarily adds CPU cores on top of the instance's original specification, rather than permanently changing the instance specification. Therefore, scale-up and scale-back are a pair of reversible operations:
Scale-up: After you enable custom scale-up, the system immediately adds the number of CPU cores you specify based on the original specification. The additional computing power is then put into use, eliminating the need to repurchase or change the instance specification. Before you manually disable it, the scale-up portion remains effective and is billed based on usage duration.
Scale-back: After you manually disable it, the system scales the number of CPU cores back to the original specification, and billing for the scale-up portion stops simultaneously. Because the scale-up does not change the instance's original specification, the instance is restored to its pre-scale-up state after the scale-back.
Note:
CPU elastic scale-out does not include additional IOPS resources. TencentDB for MongoDB currently does not impose granular restrictions on IOPS. Therefore, IOPS does not change with the number of CPU cores.
Number of cores for scale-out
The number of CPU cores added in a single custom scale-out operation is subject to the following upper limit rule:
Maximum number of additional cores = MIN (CPU cores of the current smallest shard, 24 cores).
Replica set instances: The number of CPU cores can be increased by up to 24 based on the original number.
Sharded cluster instances: The scale-out limit for a single shard is the smaller value between the smallest number of cores among all current shards and 24 cores. Elastic scale-out is performed for all shards collectively.
Scale-Out Results for Sharded Clusters
Elastic scale-out is performed on sharded cluster instances as a whole. This allows for scenarios where scale-out succeeds for some shards but fails for others:
All scale-out are successful: The execution status is Scale-out successful.
Scale-out partially successful: The execution status is Scale-out partially successful. For shards where the scale-up failed, alarms are triggered by the backend.
Use Limits
|
Maximum original vCPU cores | The original CPU cores of an instance cannot exceed 32. For example, an instance with an original specification of 48 cores does not support enabling the CPU elastic scale-up feature. | When the original specification exceeds 32 cores and computing power needs to be increased, you can directly upgrade the instance specification by changing the configuration. |
Maximum vCPU cores per scale-up | The number of cores added in a single scale-up is MIN (the number of cores of the current smallest shard, 24 cores). | If the required computing power exceeds the single scale-up limit, it is recommended to upgrade the original specification by changing the configuration. |
Instance Version | The MongoDB version of the instance must be 4.0 or later. | For instances with a version lower than 4.0, you must first upgrade the MongoDB version and then enable elastic scale-up. |
Instance type | Instances of Cloud Disk Edition are not supported. | If you need to increase the computing power of an instance of Cloud Disk Edition, you can adjust its specification by changing the configuration. |
Continuous billing | After custom scale-up is enabled, it continues to scale up and incur charges until manually disabled, and does not automatically scale down. For details, see CPU Elastic Scale-Out Billing. | Manually disable it promptly when no additional resources are needed to avoid incurring ongoing charges. |
Feature Impact Description
Relationship with Configuration Changes
When performing configuration change operations on an instance with the CPU elastic scale-up feature enabled, note the following impacts:
Adjusting Mongod node specifications: After you manually complete the configuration adjustment, the CPU elastic scale-up feature is automatically disabled. Monitor the CPU usage of your workload after the specification change. If you need to continue using elastic scale-up, manually re-enable it after the change.
Scaling Mongod nodes or changing Mongos: During the entire operation, elastic scale-up temporarily becomes invalid and does not trigger scale-up. After the operation is completed, the elastic scale-up feature automatically recovers and takes effect according to the rule.
Relationship with Other Processes
Non-interlocking processes: The CPU addition process triggered by elastic scale-up is not interlocked with non-essential interlocking processes such as cloning, backup, and full-instance rollback, and can be executed concurrently.
Interruptible processes: The task priority of elastic scale-up is lower than that of manual configuration changes by customers. Enabling elastic scale-up does not block vertical or horizontal scaling. When your workload needs to handle prolonged peak periods, you can interrupt the elastic scale-up process by manually upgrading the configuration.
Blocked scenarios: When an instance is in a mutually exclusive process, such as Mongod horizontal sharding or Mongos horizontal or vertical scaling, the CPU addition process triggered by enabling elastic scale-up is blocked.
Event alarm
CPU elastic scale-up provides the following event alarms. You can configure to receive them in the event alarms.
|
Elastic scale-out succeeded. | The CPU of the instance was elastically scaled up successfully. |
Elastic scale-out failed. | The CPU of the instance failed to elastically scale up. |
Elastic scale-out partially succeeded. | Some shards of the sharded cluster instance are scaled up successfully, while others fail. |
Elastic scale-out skipped. | The instance is in a scenario such as a mutually exclusive process, and this scale-up is skipped. |