Serverless clusters enable resource scaling depending on your workloads and free you from complex resource evaluation and O&M. This topic describes how a serverless cluster works and its benefits and scenarios.
Databases are a very important part of the IT system of modern enterprises. When you create clusters, you are often conservative to configure the resources such as CPU, memory, storage, and connections and other parameters to ensure that clusters can run smoothly even during peak periods. In this case, your resources are idle during off-peak periods and may be insufficient during peak periods. Serverless clusters can solve this problem. Serverless clusters enable resource scaling depending on your workloads and free you from complex resource evaluation and O&M.
The preceding figure provides the following information:- Common cluster: A lot of resources are wasted during off-peak hours. During peak hours, resources are insufficient and business cannot be processed.
- Serverless cluster:
- Serverless clusters scale resources based on your business requirements, and a small number of resources are wasted. This improves the resource usage.
- Serverless clusters can provide sufficient resources during peak hours, which ensures the performance and service stability.
- The pay-as-you-go billing method can save costs and resources are allocated dynamically to match workloads.
- No manual configuration changes are required. This improves O&M efficiency and frees O&M and R&D personnel.
- The automatic start and stop feature is supported for serverless clusters. When no requests are sent to the cluster, the cluster is automatically suspended to release computing resources. When the cluster receives requests, the cluster automatically starts. Note You can enable or disable the automatic cluster suspension feature for a serverless cluster with defined specifications.
- Optimizations are implemented for high-throughput writes and high-concurrency operations with elastic scaling to suit the scenarios in which large amounts of data and large traffic fluctuations are involved.
How it works
- If you use serverless clusters, you are charged based on the on-demand resources that are used to run your workloads. This significantly reduces costs.
- Serverless clusters optimize high-throughput write operations and high-performance batch processing operations and support auto scaling. This is suitable for scenarios in which large amounts of data and large traffic fluctuations are involved.
- Cluster resource scaling can be completed within a second and without service interruption.
You can create a serverless cluster and use the serverless feature from scratch. This is called a serverless cluster. You can also enable the serverless feature for a common cluster. This is called a serverless cluster with defined specifications.
- Serverless PolarProxy
Serverless PolarProxy uses the serverless architecture and is scaled independent of compute nodes. PolarProxy specifications are not user-defined. Serverless proxy resources are measured in PCUs. A PCU is approximately equal to 1 core and 2 GB of memory.
- Scale compute nodes of a serverless cluster
Both the primary node and read-only nodes adopt the serverless architecture. They can scale with workloads and share distributed storage within a single zone.
For a primary or read-only node of a serverless cluster, the PolarDB for MySQL continuously tracks the PCU usage. If the current PCUs of the primary node or read-only node are insufficient for the workloads, the serverless cluster scales out to use more PCUs. If the current PCUs of the primary node or read-only node exceed the required value, the serverless cluster scales in to reduce PCUs. Nodes in a serverless cluster can be scaled independent of each other. However, one read-only node must be scaled together with the primary node. If the specifications of a read-only node vary significantly from those of the primary node, scaling the read-only node is triggered. Nodes are scaled in units of 0.5 PCUs. If more current PCUs are used by a node, more PCUs are added or removed in the scaling. Serverless compute resources are measured in PCUs. A PCU is approximately equal to 1 core and 2 GB of memory. You can specify the range (1 PCU to 32 PCUs) for scaling a single-node. Scaling a primary or read-only node means the number of PCUs for the node increases or decreases. The system monitors the PCU of the compute node every second.
Note The maximum number of connections for a serverless cluster is 10500. - Serverless cluster storage
A serverless architecture is used for storage. Therefore, you do not need to specify the storage capacity when you purchase clusters. The storage capacity is automatically increased when the amount of data increases. You are charged for only the storage that you use. On the Overview page of the cluster, you can view Database Storage Usage. For more information, see View the database storage usage.
- PolarProxy of a serverless cluster with defined specifications
The PolarProxy is composed of the proxy resources of a common cluster and the serverless proxy resources. The proxy resources of a common cluster are specified when the common cluster is created. Serverless proxy resources are scaled independent of compute nodes and not user-defined. Serverless proxy resources are measured in PCUs. A PCU is approximately equal to 1 core and 2 GB of memory.
- Scale compute nodes of a serverless cluster with defined specifications
For a serverless cluster with defined specifications, the resources of the primary node and read-only nodes include defined-specification resources and serverless resources. The defined-specification resources cannot be scaled, while the serverless resources can be scaled depending on workloads.
For a primary or read-only node of a serverless cluster, the PolarDB for MySQL continuously tracks the PCU usage. If the current PCUs of the primary node or read-only node are insufficient for the workloads, the serverless cluster scales out to use more PCUs. If the current PCUs of the primary node or read-only node exceed the required value, the serverless cluster scales in to reduce PCUs. Nodes in a serverless cluster can be scaled independent of each other. However, one read-only node must be scaled together with the primary node. If the specifications of a read-only node vary significantly from those of the primary node, scaling the read-only node is triggered. Nodes are scaled in units of 0.5 PCUs. If more current PCUs are used by a node, more PCUs are added or removed in the scaling. Serverless compute resources are measured in PCUs. A PCU is approximately equal to 1 core and 2 GB of memory. You can specify the range (1 PCU to 32 PCUs) for scaling a single-node. Scaling a primary or read-only node means the number of PCUs for the node increases or decreases. The system monitors the PCU of the compute node every second.
Note The maximum number of connections for a serverless cluster with defined specifications is consistent with that for a common cluster with defined specifications. For more information, see Specifications of compute nodes in different editions. - Storage of a serverless cluster with defined specifications
The storage capacity of the common cluster with defined specifications is used. For more information, see Storage overview.
Fees
The fees include compute node fees, storage capacity fees, backup storage fees (only for the part exceeding the free quota), and SQL Explorer fees (optional). For more information, see Billing of serverless clusters.
The fees include the fees of the common cluster and the fees of the serverless feature. For more information about the fees of a common cluster, see Billable items overview. For more information about the fees of the serverless feature, see Billing of serverless clusters.
Benefits
- High availability
The multi-node architecture ensures the high availability of serverless clusters. Serverless clusters offers the same service level agreement (SLA) as common clusters to ensures stability.
- High scalability
- Wide range
PolarDB for MySQL serverless supports automatic scale-in/out and provides the widest scaling range in the industry. A single cluster can be scaled between 0 to 1000 cores.
- Scalability in seconds
Workload detection is accomplished in five seconds and cluster resources are scaled out within a second when your workloads increase. If your workloads decrease, cluster resources are automatically released in a tiered manner.
- No business interruption
The scaling process has no impact on business.
- Wide range
- Strong data consistency
Global consistency is provided in high-performance mode. Clusters support strong data consistency. Data can be read immediately after it is written to read-only nodes, while the performance is almost the same as in weak consistency mode.
- Cost-effectiveness
Serverless clusters are billed in PCUs to save costs. Costs can be reduced by up to 80%.
- Zero O&M
The PolarDB for MySQL serverless team takes responsibility for all operations and maintenance work such as system upgrades, system deployment, scaling, and alert processing. These operations are carried out in the background, and do not affect the services running on the system. This ensures continuous service delivery and allows you to focus on developing your business.
Scenarios
- Infrequent access to databases, such as development and test environments
- Software as a service (SaaS) scenarios, such as website building of small and medium-sized enterprises
- Individual developers
- Educational scenarios, such as teaching and student experiments
- Uncertain load scenarios, such as IoT and edge computing
- Scenarios in which services are changing or unpredictable
- Enterprise-level databases for medium- and large-sized users
- Satisfying fluctuation requirements based on existing PolarDB for MySQL clusters
Limits
- The serverless feature cannot be enabled for PolarDB for MySQL 5.6 clusters.
- Serverless clusters do not support Hot standby storage cluster, zone-level disaster recovery, or zone switching.
- Serverless clusters do not support the following features: global database network (GDN), cold data archiving, Multi-master Cluster (Database/Table) Edition, X-Engine Edition, and in-memory column index (IMCI).
- Serverless clusters do not support features such as Add or remove read-only nodes,Manually upgrade or downgrade a PolarDB cluster,Temporary upgrade,Automatically scale local resources,Automatic configuration changes (auto scaling), andCreate a custom cluster endpoint.
- Cluster versions:
- If the version of a PolarDB for MySQL cluster is 5.7, the revision version of the cluster must be 5.7.1.0.26 or later.
- If the version of a PolarDB for MySQL cluster is 8.0.1, the revision version of the cluster must be 8.0.1.1.30.1 or later.
- If the version of a PolarDB for MySQL cluster is 8.0.2, the revision version of the cluster must be 8.0.2.2.15 or later.
- The serverless feature cannot be enabled for PolarDB for MySQL 5.6 clusters.
- Serverless clusters with defined specifications do not support the following features: GDN, cold data archiving, Multi-master Cluster (Database/Table) Edition, X-Engine Edition, and IMCI.
- The serverless feature cannot be used together with the Automatically scale local resources or Automatic configuration changes (auto scaling) feature. After you enable the serverless feature for a cluster with defined specifications, you cannot enable the Automatically scale local resources or Automatic configuration changes (auto scaling) feature. Similarly, after you enable the Automatically scale local resources and Automatic configuration changes (auto scaling) features for a cluster with defined specifications, you cannot enable the serverless feature for the cluster.
- The serverless feature cannot be enabled for a standalone node of the Cluster Edition. If you want to enable the feature, you must add read-only nodes. For more information, see the Add a read-only node section of the "Add or remove read-only nodes" topic.