Help Center/ GaussDB/ Best Practices/ Scaling Best Practices
Updated on 2025-03-10 GMT+08:00
View PDF
Share

Scaling Best Practices

With GaussDB, you can scale your instance by changing CPU and memory specifications, increasing or decreasing storage, and adding or removing nodes and shards as needed. This allows for flexible adjustment of database performance and capacity to adapt to changing workload demands.

Changing CPU and Memory Specifications

To adjust to changing workloads, you can scale up or down an instance by changing its CPU and memory specifications. For details, see Changing the CPU and Memory Specifications of a GaussDB Instance.

Increasing or Decreasing Storage

You are advised to resize your instance storage in the following scenarios:

  • As GaussDB instances continue to operate over time, the amount of data to be stored can grow rapidly, potentially surpassing the original storage capacity. At this point, you can scale up the storage of your DB instance.
  • When the storage usage exceeds a certain threshold (85% by default, but this can be modified using the cms:datastorage_threshold_value_check parameter), the GaussDB instance is set to a read-only state and no more data can be written to it. You can avoid this situation by scaling up the instance storage to ensure service continuity.

For details, see Scaling Up Storage Space.

Adding or Deleting Coordinator Nodes

When the number of concurrent requests increases significantly, you can add more coordinator nodes (CNs) to increase the concurrent processing capacity of your instance. For details, see Adding Coordinator Nodes for an Instance.

On the other hand, if business activity decreases, some CNs are left idle. You can reduce the number of CNs to improve resource efficiency. For details, see Deleting Coordinator Nodes for an Instance.

CNs can only be added or deleted for distributed instances using independent deployment.

Adding or Deleting Shards

As data volume continues to grow, the existing data nodes (DNs) may become unable to accommodate the increased load. To address this, you can scale out the instance by adding more shards to it to distribute data. For details, see Adding Shards for an Instance.

Conversely, there may be more than enough DNs in your instance after read/write splitting is enabled or redundant data is cleared. You can delete shards as needed to avoid cost waste. For details, see Deleting Shards for an Instance.

Shards can only be added or deleted for distributed instances using independent deployment.