- Release Notes and Announcements
- Release Notes
- Announcements
- Commercial Billing for Database Proxy
- TencentDB for MySQL Audit Upgrade
- Added Authentication APIs
- API Authentication Upgrade
- TencentDB for MySQL API 2.0 Discontinuation
- Monitoring Module Upgrade in Shanghai Region
- Monitoring Metric Optimization
- Network Architecture Upgrade
- Change of APIs for Querying the Specifications of Purchasable Database Instances
- Replacement of Certain Old Database Proxy APIs
- Added Advanced Monitoring Metrics
- Change of Calculation Formula for Memory Utilization
- Monitoring Module Upgrade and Optimization in Guangzhou and Shanghai Regions
- Monitoring Module Upgrade
- Parameter Template and Instance Purchase Process Optimization
- Binlog Will Take up Disk Space
- User Tutorial
- Product Introduction
- Tencent Kernel TXSQL
- Overview
- Kernel Version Release Notes
- Functionality Features
- Performance Features
- Security Features
- Stability Features
- TXRocks Engine
- Purchase Guide
- Getting Started
- Database Audit
- Operation Guide
- Use Limits
- Operation Overview
- Instance Management and Maintenance
- Instance Upgrade
- CPU Elastic Expansion
- Read-Only/Disaster Recovery Instances
- Database Proxy
- Account Management
- Database Management Center (DMC)
- Parameter Configuration
- Network and Security
- Backup and Rollback
- Data Migration
- Monitoring and Alarms
- Operation Logs
- Tag
- Best Practices
- Usage Specifications of TencentDB for MySQL
- Configuring Automatic Application Reconnection
- Impact of Modifying MySQL Source Instance Parameters
- Limits on Automatic Conversion from MyISAM to InnoDB
- Creating VPCs for TencentDB for MySQL
- Enhancing Business Load Capacity with TencentDB for MySQL
- Setting up 2-Region-3-DC Disaster Recovery Architecture
- Improving TencentDB for MySQL Performance with Read/Write Separation
- Migrating Data from InnoDB to RocksDB with DTS
- Building LAMP Stack for Web Application
- Building Drupal Website
- Building All-Scenario High-Availability Architecture
- Calling MySQL APIs in Python
- White Paper
- Troubleshooting
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- StopCpuExpand
- StartCpuExpand
- DescribeCpuExpandStrategy
- AddTimeWindow
- BalanceRoGroupLoad
- CloseWanService
- CreateDBInstance
- CreateDBInstanceHour
- CreateRoInstanceIp
- DeleteTimeWindow
- DescribeCdbZoneConfig
- DescribeDBFeatures
- DescribeDBInstanceCharset
- DescribeDBInstanceConfig
- DescribeDBInstanceGTID
- DescribeDBInstanceInfo
- DescribeDBInstanceRebootTime
- DescribeDBSwitchRecords
- DescribeRoGroups
- DescribeRoMinScale
- DescribeTagsOfInstanceIds
- DescribeTimeWindow
- InitDBInstances
- IsolateDBInstance
- ModifyAutoRenewFlag
- ModifyDBInstanceName
- ModifyDBInstanceProject
- ModifyDBInstanceVipVport
- ModifyInstanceTag
- ModifyRoGroupInfo
- ModifyTimeWindow
- OfflineIsolatedInstances
- OpenDBInstanceEncryption
- OpenDBInstanceGTID
- OpenWanService
- ReleaseIsolatedDBInstances
- RenewDBInstance
- RestartDBInstances
- StartReplication
- StopReplication
- SwitchDBInstanceMasterSlave
- SwitchDrInstanceToMaster
- SwitchForUpgrade
- UpgradeDBInstance
- UpgradeDBInstanceEngineVersion
- DescribeDBInstances
- DescribeDBZoneConfig
- CreateDeployGroup
- DeleteDeployGroups
- DescribeDeployGroupList
- ModifyNameOrDescByDpId
- Data Import APIs
- Database Proxy APIs
- AdjustCdbProxy
- AdjustCdbProxyAddress
- CloseCdbProxyAddress
- CreateCdbProxy
- CreateCdbProxyAddress
- DescribeCdbProxyInfo
- DescribeProxySupportParam
- ModifyCdbProxyAddressDesc
- ModifyCdbProxyAddressVipAndVPort
- ModifyCdbProxyParam
- CloseCDBProxy
- DescribeProxyCustomConf
- ReloadBalanceProxyNode
- SwitchCDBProxy
- UpgradeCDBProxyVersion
- Database Audit APIs
- Security APIs
- Task APIs
- Account APIs
- Backup APIs
- DescribeBackupDecryptionKey
- CreateBackup
- DeleteBackup
- DescribeBackupDownloadRestriction
- DescribeBackupEncryptionStatus
- DescribeBackupOverview
- DescribeBackupSummaries
- DescribeBinlogBackupOverview
- DescribeDataBackupOverview
- DescribeLocalBinlogConfig
- DescribeRemoteBackupConfig
- DescribeSlowLogs
- ModifyBackupDownloadRestriction
- ModifyBackupEncryptionStatus
- ModifyLocalBinlogConfig
- ModifyRemoteBackupConfig
- DescribeBackups
- DescribeBackupConfig
- ModifyBackupConfig
- DescribeBinlogs
- Rollback APIs
- Parameter APIs
- Database APIs
- Monitoring APIs
- Log-related API
- Data Types
- Error Codes
- FAQs
- Service Agreement
- Reference
- Glossary
- Contact Us
- Preset Plugin List
- Release Notes and Announcements
- Release Notes
- Announcements
- Commercial Billing for Database Proxy
- TencentDB for MySQL Audit Upgrade
- Added Authentication APIs
- API Authentication Upgrade
- TencentDB for MySQL API 2.0 Discontinuation
- Monitoring Module Upgrade in Shanghai Region
- Monitoring Metric Optimization
- Network Architecture Upgrade
- Change of APIs for Querying the Specifications of Purchasable Database Instances
- Replacement of Certain Old Database Proxy APIs
- Added Advanced Monitoring Metrics
- Change of Calculation Formula for Memory Utilization
- Monitoring Module Upgrade and Optimization in Guangzhou and Shanghai Regions
- Monitoring Module Upgrade
- Parameter Template and Instance Purchase Process Optimization
- Binlog Will Take up Disk Space
- User Tutorial
- Product Introduction
- Tencent Kernel TXSQL
- Overview
- Kernel Version Release Notes
- Functionality Features
- Performance Features
- Security Features
- Stability Features
- TXRocks Engine
- Purchase Guide
- Getting Started
- Database Audit
- Operation Guide
- Use Limits
- Operation Overview
- Instance Management and Maintenance
- Instance Upgrade
- CPU Elastic Expansion
- Read-Only/Disaster Recovery Instances
- Database Proxy
- Account Management
- Database Management Center (DMC)
- Parameter Configuration
- Network and Security
- Backup and Rollback
- Data Migration
- Monitoring and Alarms
- Operation Logs
- Tag
- Best Practices
- Usage Specifications of TencentDB for MySQL
- Configuring Automatic Application Reconnection
- Impact of Modifying MySQL Source Instance Parameters
- Limits on Automatic Conversion from MyISAM to InnoDB
- Creating VPCs for TencentDB for MySQL
- Enhancing Business Load Capacity with TencentDB for MySQL
- Setting up 2-Region-3-DC Disaster Recovery Architecture
- Improving TencentDB for MySQL Performance with Read/Write Separation
- Migrating Data from InnoDB to RocksDB with DTS
- Building LAMP Stack for Web Application
- Building Drupal Website
- Building All-Scenario High-Availability Architecture
- Calling MySQL APIs in Python
- White Paper
- Troubleshooting
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- StopCpuExpand
- StartCpuExpand
- DescribeCpuExpandStrategy
- AddTimeWindow
- BalanceRoGroupLoad
- CloseWanService
- CreateDBInstance
- CreateDBInstanceHour
- CreateRoInstanceIp
- DeleteTimeWindow
- DescribeCdbZoneConfig
- DescribeDBFeatures
- DescribeDBInstanceCharset
- DescribeDBInstanceConfig
- DescribeDBInstanceGTID
- DescribeDBInstanceInfo
- DescribeDBInstanceRebootTime
- DescribeDBSwitchRecords
- DescribeRoGroups
- DescribeRoMinScale
- DescribeTagsOfInstanceIds
- DescribeTimeWindow
- InitDBInstances
- IsolateDBInstance
- ModifyAutoRenewFlag
- ModifyDBInstanceName
- ModifyDBInstanceProject
- ModifyDBInstanceVipVport
- ModifyInstanceTag
- ModifyRoGroupInfo
- ModifyTimeWindow
- OfflineIsolatedInstances
- OpenDBInstanceEncryption
- OpenDBInstanceGTID
- OpenWanService
- ReleaseIsolatedDBInstances
- RenewDBInstance
- RestartDBInstances
- StartReplication
- StopReplication
- SwitchDBInstanceMasterSlave
- SwitchDrInstanceToMaster
- SwitchForUpgrade
- UpgradeDBInstance
- UpgradeDBInstanceEngineVersion
- DescribeDBInstances
- DescribeDBZoneConfig
- CreateDeployGroup
- DeleteDeployGroups
- DescribeDeployGroupList
- ModifyNameOrDescByDpId
- Data Import APIs
- Database Proxy APIs
- AdjustCdbProxy
- AdjustCdbProxyAddress
- CloseCdbProxyAddress
- CreateCdbProxy
- CreateCdbProxyAddress
- DescribeCdbProxyInfo
- DescribeProxySupportParam
- ModifyCdbProxyAddressDesc
- ModifyCdbProxyAddressVipAndVPort
- ModifyCdbProxyParam
- CloseCDBProxy
- DescribeProxyCustomConf
- ReloadBalanceProxyNode
- SwitchCDBProxy
- UpgradeCDBProxyVersion
- Database Audit APIs
- Security APIs
- Task APIs
- Account APIs
- Backup APIs
- DescribeBackupDecryptionKey
- CreateBackup
- DeleteBackup
- DescribeBackupDownloadRestriction
- DescribeBackupEncryptionStatus
- DescribeBackupOverview
- DescribeBackupSummaries
- DescribeBinlogBackupOverview
- DescribeDataBackupOverview
- DescribeLocalBinlogConfig
- DescribeRemoteBackupConfig
- DescribeSlowLogs
- ModifyBackupDownloadRestriction
- ModifyBackupEncryptionStatus
- ModifyLocalBinlogConfig
- ModifyRemoteBackupConfig
- DescribeBackups
- DescribeBackupConfig
- ModifyBackupConfig
- DescribeBinlogs
- Rollback APIs
- Parameter APIs
- Database APIs
- Monitoring APIs
- Log-related API
- Data Types
- Error Codes
- FAQs
- Service Agreement
- Reference
- Glossary
- Contact Us
- Preset Plugin List
MySQL supports manual scaling of the current instance's CPU upper limit and automatic scaling based on set CPU average usage thresholds and observation periods. This provides better mitigation for sudden request performance pressure, accommodating peak business traffic and ensuring online business stability. This section provides a brief overview of the CPU Elastic Expansion feature.
Background
In many business scenarios, peak traffic periods or sudden traffic surges can impose tremendous pressure on server loads. The CPU utilization of the application can skyrocket, and if CPU resources are not scaled in a timely manner, it could lead to system performance degradation, increased request response time, and other issues, severely affecting user experience and satisfaction. Beyond burst traffic scenarios, situations such as low cache hit rate in the database, ineffective indexes, database deadlocks, complex database query statements, a high volume of concurrent updates, coupled with insufficient hardware configurations, can also lead to CPU overloads.
Traditional Solutions
Upon detecting a CPU overload, users typically manually upgrade it through the console and wait for the upgrade to be completed. The upgrade duration, influenced by the amount of data, is uncertain. Moreover, the upgrade process may result in transient disruptions, affecting regular operations. After the business traffic become normal after the upgrade, users need to manually apply for a downgrade through the console. Thus, the traditional solution poses challenges such as the necessity for rapid response, unpredicted time frames, risk of transient disruptions, and an extensive follow-up workload.
CPU Elastic Scaling
The CPU Elastic Scaling feature, underpinned by the advantages of the cloud environment, allows for the dynamic assignment of CPU resources. As the database traffic increases or CPU resource usage escalates, it can automatically allocate more CPU resources, then scale in after peak periods. Users can choose whether to enable the CPU Elastic Scaling feature via the console, and dynamically configure the database's CPU resources based on the business needs and traffic volume. Consequently, elastic scaling can be achieved to handle peak pressure, ensuring superior performance, high availability, and stability of the database instance.
Feature Type
The CPU Elastic Scaling feature can be categorized into automatic scaling and manual scaling. If automatic scaling is enabled, you need to set the thresholds for both scale-out and scale-in. For manual scaling, you need to set the number of CPU cores to be added, and manual scaling doesn't automatically scale in - it must be manually stopped.
Automatic scale-out
Auto scale-out
Upon enabling CPU Elastic Scaling -> Auto Scaling, when the average CPU utilization of the database instance within the observation window reaches the set threshold, the system will double the number of CPU cores on the basis of the original computing specification. For instance, if the original computing specification has 4 cores, it will be increased to 8 cores. Concurrently, the IOPS of the instance will also rise. For each additional core, the IOPS increases by 1,000. If the user's Tencent Cloud account balance is insufficient or there are not enough CPU resources on the host (which rarely occurs), the scaling will not proceed, and a scaling failure event will be generated later.
Note：
Only supports doubling the number of CPU cores based on the original computing specification, and no further increase is supported. For instance, after the original CPU cores are doubled to 8, it cannot be increased to 16.
Auto Scale-in
Upon enabling CPU Elastic Scaling -> Auto Scaling, during the set observation window for auto scale-in, if the CPU utilization is below the set threshold, the system will automatically reduce both the CPU cores and IOPS to the original computing specifications.
Note：
After enabling CPU Elastic Scaling -> Auto Scaling, the system will monitor the database instance based on the most recent configuration parameters. When the instance meets the conditions for automatic scale-in, the system will automatically scale in the instance.
For details about the operations of enabling auto-scaling, disabling auto-scaling, and setting the scale-in and scale-out thresholds, see Setting Auto Scaling.
Manual scaling
Manual Scale-out
When CPU Elastic Scaling -> Manual Scaling is enabled, the instance operates according to the number of CPU cores after scale-out.
Manual Scale-in
Upon enabling CPU Elastic Scaling -> Manual Scaling, when business no longer requires additional CPU resources, users must manually disable CPU Elastic Scaling, otherwise charges will continue.
For details about the operations of enabling and disabling manual scaling, see Setting Manual Scaling.
Comparison between Automatic and Manual Scaling
Feature Type | Screenshot After Successful Feature Enabling | CPU Upper Limit | Scale-in Process | Event Alarm | Billing |
Auto Scaling |  | Twice the original number of CPU cores | Automatically scales in according to the set scale-in threshold. | Support | Billing begins only after auto scale-out is successfully triggered, and ceases after the scale-in. |
Manual Scaling |  | Supports 1-core unit scale-out, up to twice the original number of CPU cores. | Unable to automatically scale in, manual stop of scaling is required. After manual scaling is stopped, the system immediately scales in to the original CPU core count. | Support | Billing will continue from the enabling of manual scaling until it is disabled. |
Event Alarm Explanation
For both automatic and manual scaling out, relevant event alarms can be set and configured for notifications. The following are the event metrics and descriptions related to the CPU Elastic Scaling feature.
Scaling Type | Event Metrics | Description |
Auto Scaling | CPUExpansion | Automatic CPU scale-out is successful. |
| CPUExpansionFailed | Automatic CPU scale-out failed. |
| CPUConstraction | Automatic CPU scale-in is successful. |
Manual Scaling | CPUExpansion | Manual CPU scale-out is successful. |
| CPUExpansionFailed | Manual CPU scale-out failed. |
| CPUConstraction | Manual CPU scale-out is stopped. |
There are two causes for automatic and manual scaling failures: insufficient balance in the Tencent Cloud account of the user or inadequate CPU resources on the host (rarely occurs).If insufficient account balance leads to a scaling failure, users can recharge their account and retry. For other causes, please submit a ticket for assistance.
Feature Impact Overview
The CPU Elastic Scaling feature is concurrently deployed on both primary and secondary nodes on two-node and three-node instances. Therefore, if an HA switch occurs after the CPU Elastic Scaling feature is enabled, the switched-to node will also reach the scaled-out CPU specifications. After automatic scale-in or stop of manual scaling, the system will restore to the original CPU specifications.
The feature should be separately enabled for read-only instances and disaster recovery instances, which will not simultaneously scale out. In other words, the read-only instances and disaster recovery instances attached to the primary instance will not simultaneously expand their CPU resources even after the CPU Elastic Scaling feature of the primary instance is triggered. The CPU Elastic Scaling feature must be enabled for these two types of instances separately.
Related Operations
Yes
No
Was this page helpful?