Sign inTry Free

Scale a Cluster

On this page

A cluster can be scaled up or down horizontally and vertically.

Horizontal Scaling

Scaling a cluster up or down horizontally means increasing or decreasing the number of nodes available. The number of child aggregator and leaf nodes can be adjusted independently.

To adjust the number (count) of aggregators, edit the spec.aggregatorSpec.count field in the sdb-cluster.yaml file.

The value of this field is the sum of the number of Master Aggregators and child aggregators. There is only one Master Aggregator, so the number of child aggregators is always spec.aggregatorSpec.count - 1. Only the Master Aggregator will be deployed when this field is set to 1.

To adjust the number of leaf nodes, edit the spec.leafSpec.count field in the sdb-cluster.yaml file. This value will be the number of leaf nodes in one availability group (AG).

Vertical Scaling

Scaling a cluster up or down vertically means increasing or decreasing the resource capacity in each node. The following resources can be scaled up or down.

CPU

The CPU can be scaled up or scaled down. Set the CPU request and CPU limit directly using the following fields in the sdb-cluster.yaml file:

  • cores: The number of vCPUs requested for each pod.

  • coresLimit: The maximum number of vCPUs each pod can use.

For example, to allocate 8 vCPUs to each aggregator, add the following in the sdb-cluster.yaml file:

aggregatorSpec:
    cores: 8
    coresLimit: 8

The cores and coresLimit values are passed to the pod template as the CPU resource request and CPU resource limit, respectively. Refer to Assign CPU Resources to Containers and Pods for more information on Kubernetes CPU resource allocation.

Memory

Memory can be scaled up or down. Set the memory request and memory limit directly using the following fields in the sdb-cluster.yaml file:

  • memoryMB:  Specifies the amount of memory requested for each pod, in megabytes.

  • memoryLimitMB:  Specifies the maximum amount of memory each pod can use, in megabytes.

For example, to allocate 64GB of memory to each aggregator:

aggregatorSpec:
    memoryMB: 65536
    memoryLimitMB: 65536

The memoryMB and memoryLimitMB values are passed to the pod template as the memory resource request and memory resource limit, respectively. Refer to Assign Memory Resources to Containers and Pods for more information on Kubernetes memory resource allocation.

Note

The height parameter is deprecated. Use cores, coresLimit, memoryMB, and memoryLimitMB for explicit control over resource allocation.

Storage

Storage can only be scaled up, and scaling up is only possible if the defined StorageClass has allowVolumeExpansion set to true.

The following fields in sdb-cluster.yaml control the persisted volume size for each pod, which must be expressed as integer values:

  • spec.aggregatorSpec.storageGB

  • spec.leafSpec.storageGB

  1. To scale up storage, ensure that there is available storage space and increase these values to the desired amount.

  2. Apply the new values.

    kubectl apply -f sdb-cluster.yaml

Last modified:

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In