Enable Aerospike Strong Consistency (Read‑After‑Write) Across a Cluster

Desired Outcome

Configure every node in an Aerospike cluster so that a read performed immediately after a write always returns the latest value. This linearizable, read‑after‑write guarantee is essential for applications that cannot tolerate stale data, such as financial transaction logs or real‑time inventory counters.

Prerequisites

• Aerospike Server 5.7 or newer installed on all nodes.
• SSD storage with a write‑buffer‑size large enough for your peak write rate (typical recommendation: 50 MiB or more).
• Network latency between nodes < 2 ms; high‑speed interconnects (e.g., Infiniband or 10 GbE).
• Replication factor of at least 2 (recommended 3 for production).
• Full cluster restart privileges (root or sudo).

Procedure

1. Edit the namespace configuration

   Open /opt/aerospike/etc/aerospike.conf on each node and locate the namespace block. Add the flag under the storage-engine section:

   [namespace test]
       replication-factor 2
       storage-engine device
           device /dev/nvme0n1
           file /opt/aerospike/data/test.db
           write-block-size 128
           write-buffer-size 64
           strong-consistency true
       

   Replace /dev/nvme0n1 and /opt/aerospike/data/test.db with your actual SSD device and data file path.

2. Restart Aerospike

   On each node run:

   sudo systemctl restart aerospike
   # or if using init.d
   sudo service aerospike restart
   

   Verify that the service comes up without errors.

3. Confirm the flag is active

   Execute on every node:

   sudo asinfo -v "strong-consistency:get-config=true"
   # Expected output: true
   

   Check the node log (/var/log/aerospike/aerospike.log) for a line like strong-consistency enabled.

4. Run a read‑after‑write test

   Using Aerospike Query Language (AQL) or the client API, perform a write followed immediately by a read on the same key. Example with AQL:

   aql -e "INSERT INTO test.myset (key) VALUES ('testkey', 123);"
   aql -e "SELECT * FROM test.myset WHERE key = 'testkey';"
   # The SELECT should return 123.
   

   Alternatively, use asbenchmark with a read‑after‑write workload to measure latency percentiles.

Verification Checklist

• asinfo output shows true for strong-consistency:get-config=true on every node.
• Cluster log entry confirms strong-consistency enabled during startup.
• Read‑after‑write test returns the most recent value without error.
• Benchmark shows 99th‑percentile read latency within acceptable limits (e.g., < 5 ms for 2‑node cluster).

Recovery Options

• If write timeouts or high latency appear, revert the flag:

  [namespace test]
      ...
      strong-consistency false
      

  Then restart all nodes.
• Monitor the strong-consistency-errors metric via asinfo -v "metrics:strong-consistency-errors". Persistent errors suggest SSD write‑buffer under‑provisioning; increase write-buffer-size or add more SSD capacity.
• Ensure no node in the cluster has a mismatched setting; otherwise, the cluster may experience split‑brain or inconsistent reads.

Limitations & Practical Tips

• Strong consistency increases write latency by up to 2× in high‑throughput workloads. Test under realistic traffic before deploying to production.
• All nodes must share the same setting; partial deployment is unsupported.
• SSD endurance matters: frequent writes under strong consistency can accelerate wear. Monitor ssd-health metrics if available.
• For workloads that tolerate eventual consistency, consider disabling the flag to regain throughput.