Skip to main content
Version: Operator 2.4.0

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 when referring to CP mode. This example lets you configure a strong consistency namespace.

In a non-AKO world, to set up a Strong Consistency namespace, configure the namespace and set the roster for this namespace. Also, 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, see the Aerospike documentation for Strong Consistency.

AKO automates the above tasks and simplifies the management of a Strong Consistency namespace. You only need to configure a Strong Consistency namespace. AKO deploys the namespace and manages the roster. AKO also validates unavailable/dead partitions before operations like rolling restart and scale-down. However, if there are any dead partitions, AKO errors out and user intervention is needed to recover those partitions. For more information on unavailable and dead partitions, see this

To set up a strong consistency namespace, Add the strong-consistency: true config in the namespace.

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

For the full CR file, see the Strong Consistency example CR 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


  • Strong Consistency config cannot be updated.
  • All racks should have the same Strong Consistent (SC) namespaces.
  • ClusterSize < replication-factor is allowed in AP mode but not in SC mode.
  • Cluster scale down and rolling restart simultaneously is not supported in Strong Consistency mode.