Skip to content

Data in memory storage configuration for Aerospike on Kubernetes

For the complete documentation index see: llms.txt

All documentation pages available in markdown.

With a data in memory (DIM) configuration, you can run an Aerospike cluster without separate persistent storage, which is useful for test clusters and for production workloads that use pure in-memory namespaces. For more information on DIM and other storage configurations, see the Aerospike documentation for namespace storage configuration.

Configure data in memory

  1. Add the following storage-specific configuration to the Aerospike cluster’s CR file.

      aerospikeConfig:
        namespaces:
          - name: test
            replication-factor: 2
            storage-engine:
              type: memory
              data-size: 1073741824

    Several examples of DIM cluster CR files are in the main Aerospike Kubernetes Operator repository.

  2. Save and exit the CR file, then use kubectl to apply the change.

    Terminal window
    kubectl apply -f aerospike-cluster.yaml

Configure data-size per node

data-size applies to each pod’s Aerospike node. AKO applies the same aerospikeConfig to every pod in a rack. In rack-aware clusters, RackConfig can override aerospikeConfig per rack, so data-size may differ between racks. Set data-size based on the memory available to a single pod. See Capacity planning and In-memory data storage and stripes for how to calculate a safe value.

Change data-size on a running cluster

Changing data-size requires clearing the pod’s existing shared memory stripes, so AKO performs a rolling full pod restart for this change. For more information, see How to change data-size configuration in a running cluster.

Before changing data-size on a running cluster, verify the following:

  • The new data-size is greater than or equal to the current per-node data usage, with headroom for growth.
  • Set replication-factor to 2 or greater before you change data-size. Each pod drops its in-memory data during the restart and rebuilds it through migration from replica copies on other nodes.
  • If replication-factor is 1, do not change data-size unless the namespace data can be discarded. Otherwise, increase the replication factor and wait for migrations to complete before changing data-size.
  • Review evict-used-pct and any other threshold expressed as a percentage of data-size. Lowering data-size shrinks the denominator and can trigger eviction sooner than expected.
  • Expect increased migration traffic and temporary latency while each pod restarts and refills.

After the change completes, confirm the namespace’s memory statistics with asadm and check the best-practices info command for violations. Confirm the Aerospike log is free of existing memory stripe size differs from config. That message indicates asd started with existing shared memory stripes that do not match the new data-size.