Skip to main content
Version: Operator 3.2.2

Strong Consistency

Aerospike's database can be configured as Available and Partition-tolerant (AP) or Consistent and Partition-tolerant (CP). Aerospike uses the term "strong consistency" (SC) when referring to CP mode.

In strong consistency mode, database writes are guaranteed to be complete or to fail, with no partial writes possible. In addition, all writes across all nodes (pods) complete in the same order they were started, without any skipping or re-ordering.

Without using the Aerospike Kubernetes Operator (AKO), to set up a strong consistency namespace, configure the namespace and set its roster. Update the roster whenever a node is added or removed from the cluster. Check for unavailable/dead partitions in the cluster before doing any operations like rolling restart and scale-down. For more information on setting up a strong consistency namespace without the Kubernetes Operator, see the Aerospike documentation for Strong Consistency.

AKO automates these tasks and simplifies the management of a strong consistency namespace. You only need to configure a strong consistency namespace rather than configure and continually manage it. AKO deploys the namespace and manages the roster. AKO also validates unavailable/dead partitions before operations like rolling restarts and scaling down.

To set up a strong consistency namespace, add the strong-consistency: true parameter in the namespace section of the custom resource (CR) file.

- name: test
replication-factor: 2
strong-consistency: true
type: device
- /test/dev/xvdf

For the full CR file, see the strong consistency example in the main Aerospike Kubernetes Operator repository.

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

kubectl apply -f aerospike-cluster.yaml


If there are any dead partitions, AKO stops with an error and user intervention is needed to recover those partitions. For more information on unavailable and dead partitions, see Validating Partition Availability.

  • SC configurations cannot be updated in place.
  • All racks should have identical SC namespaces.
  • A cluster size smaller than the replication factor is allowed in AP mode but not in SC mode.
  • Cluster scale down and rolling restart simultaneously is not supported in SC mode.