Aerospike Strong Consistency: Linearizable Reads Without Stale Data

If you need every read to return the most recent committed write across an Aerospike cluster, even during node failures and network partitions, enable Strong Consistency at namespace creation and accept the CP trade-off. Strong Consistency gives linearizable reads by requiring a quorum of replicas to agree on record state before a read or write completes. It prevents stale reads that are possible in the default Eventual Consistency mode, at the cost of higher write latency and reduced availability during severe partitions.

What Strong Consistency changes in practice

In Eventual Consistency, a write is acknowledged after the master persists it locally and replication to replicas proceeds asynchronously. A subsequent read can be served from a replica that has not yet received the update.

Strong Consistency uses a distributed consensus protocol with a commit log and generation counter. A write is not considered committed until a quorum of replicas acknowledges it. Reads require a quorum of replicas to agree on the same generation. This ensures linearizability: operations appear to execute in a single global order.

The mechanism relies on two internal constructs. A per-record generation counter monotonically increases on each successful write. A commit log tracks which replicas have durably stored a given generation. If a node fails, the surviving replicas can reconstruct the committed state from the log and generation information without data loss.

Worked namespace configuration

Strong Consistency must be set when the namespace is created. It cannot be enabled on an existing namespace. The setting lives in aerospike.conf under the namespace block.

Run on each node as a privileged user to edit the configuration file, typically /etc/aerospike/aerospike.conf. A restart of the Aerospike service is required for a new namespace to take effect. Changing an existing namespace is not supported and will be rejected.

namespace test_sc {
    replication-factor 2
    memory-size 4G
    storage-engine device {
        file /opt/aerospike/data/test_sc.dat
        filesize 32G
    }
    strong-consistency true
}

Key points in this example:

• replication-factor 2 means two copies per record. With Strong Consistency, the quorum size is derived from replication factor and the configured durability.
• strong-consistency true activates the consensus path for this namespace only. Other namespaces on the same cluster can remain in Eventual Consistency.
• No data migration path exists from an Eventual Consistency namespace to Strong Consistency. A new namespace must be created and data reloaded.

Risk: Editing aerospike.conf incorrectly can prevent the service from starting. Validate the file syntax before restarting and keep a backup of the original configuration.

Verify the mode is active

Verification should be done from an administrative node with asadm installed and network access to the cluster.

1. Check the configuration parameter is present.

   Run: sudo grep -A 10 "namespace test_sc" /etc/aerospike/aerospike.conf. Expected check: the block contains strong-consistency true. This confirms the intended configuration is on disk.

2. Inspect runtime namespace properties.

   Run: asadm -e "info namespace". Expected check: the namespace row shows strong-consistency enabled. This confirms the server has loaded the mode.

3. Application level check.

   Perform a write followed immediately by a read from a different client node. In Strong Consistency the read must return the value written. This is a logical verification of linearizability, not a guarantee of timing.

Do not rely on client timeout defaults. Incorrectly configured client timeouts can surface as application errors during replica synchronization even when the cluster is healthy. Increase client socket timeouts and operation timeouts relative to your network and replication latency.

Limits and common mistakes

Availability vs consistency

Strong Consistency is a CP choice in the CAP theorem. During a severe network partition that isolates a majority of replicas, the namespace becomes unavailable for writes rather than serving potentially stale reads. Eventual Consistency would remain available. Plan application retry and fallback behavior accordingly.

Write latency

Writes require synchronous acknowledgment from a quorum of replicas. This adds network round trips compared to Eventual Consistency. Expect higher p99 write latency. Size the cluster for lower cross-rack latency and tune commit-to-device settings if needed.

Namespace creation only

A common mistake is attempting to add strong-consistency true to an existing namespace and restarting. The server will reject the change. The only supported path is to create a new namespace with the flag set at creation time and migrate data.

Replication factor and durability

Strong Consistency requires replication-factor >= 2. A replication factor of 1 provides no quorum and is not compatible with the consistency guarantees. Also ensure persistence settings match your durability requirements; Strong Consistency protects against node loss but does not replace backups.

Use Strong Consistency when correctness of the latest write is non-negotiable, such as financial balances, inventory reservation, or access control state. For high-throughput, latency-sensitive workloads where occasional staleness is acceptable, Eventual Consistency remains the default.