Storage Configuration

Prerequisites

Before deploying your SingleStore cluster, ensure that an appropriate StorageClass is available in your Kubernetes cluster. The storageClass value specified in sdb-cluster.yaml must match an existing StorageClass resource.

Run the following command to list available storage classes:

kubectl get storageclass

When selecting a StorageClass for SingleStore, verify the following properties.

• allowVolumeExpansion

  • Must be true for production deployments to enable online volume expansion

  • If false, storage size cannot be increased after deployment

• reclaimPolicy

  • Delete automatically removes PersistentVolumes when the cluster is deleted

  • Retain preserves data after cluster deletion, while Delete automatically cleans up volumes. Select the option that meets your operational requirements and data retention policies.

• volumeBindingMode

  • Immediate provisions the volume when the PersistentVolumeClaim is created

  • WaitForFirstConsumer delays provisioning until a pod is scheduled. SingleStore recommends this value for multi-zone deployments

To inspect a specific StorageClass:

kubectl describe storageclass <class-name>

Confirm that allowVolumeExpansion is set to true for production deployments.

If a suitable StorageClass is not available, create one with volume expansion enabled. Refer to Storage Class Objects for more information.

Apply the configuration:

kubectl apply -f storageclass.yaml

Before deploying the cluster, ensure the following:

• The StorageClass exists:

  Shell

  Copy

  kubectl get storageclass <class-name>

• The StorageClass has allowVolumeExpansion set to true for production deployments

• RBAC permissions are correctly configured in sdb-rbac.yaml

Fault-Tolerant Storage Configuration

To deploy a fault-tolerant SingleStore cluster, configure the redundancyLevel and appropriate storage resources.

• redundancyLevel: 1 disables replication and is intended for development or testing

• redundancyLevel: 2 enables data replication and is required for production deployments

With redundancyLevel: 2, each partition has two replicas distributed across availability groups. A minimum of two leaf nodes is required; one node per availability group.

The following is a fault-tolerant configuration example:

apiVersion: memsql.com/v1alpha1
kind: MemsqlCluster
metadata:
name: sdb-cluster-ha
spec:
license: license_key
adminHashedPassword: "hashed_password"
nodeImage:
repository: singlestore/node
tag: alma-9.1.0
redundancyLevel: 2
aggregatorSpec:
count: 3 # Use odd numbers such as 3, 5, or 7
cores: 8
coresLimit: 8
memoryMB: 32768
memoryLimitMB: 32768
storageGB: 256
storageClass: premium-rwo
leafSpec:
count: 4 # Four leaves create two availability groups
cores: 16
coresLimit: 16
memoryMB: 131072
memoryLimitMB: 131072
storageGB: 1024
storageClass: premium-rwo

Use an odd number of voting member aggregators - typically one Master Aggregator (MA) and two or more child aggregators (CAs) configured as voting members at the time the cluster is created - to maintain quorum for cluster consensus. For example:

• Three master aggregators tolerate one failure

• Five master aggregators tolerate two failures

For child aggregators, SingleStore recommends running at least two to maintain connectivity during cluster maintenance operations.

With redundancyLevel: 2, data is replicated across leaf nodes.

• Total usable storage is approximately(leafSpec.count × leafSpec.storageGB)/ 2

• For example, four leaf nodes with 1 TB each provide approximately 2 TB of usable storage

Refer to Managing High Availability and Disaster Recovery for more information.