Detail
There are two server side parameters available for tuning consistency in Aerospike.
You may also choose the consistency levels on a per-operation basis from the clients, but the server side configurations may override the clients’ requests. The default value of both parameters is “off”, which means that the server uses the levels set by the client.
Answer
Read Consistency
If read-consistency-level-override is off and it is not set by the client, the default behavior for the server is one. The client reads the record from a single server instance.
When read-consistency-level-override is one, regardless of the client’s consistency level, the server only reads from one copy. If read-consistency-level-override is set to one, the clients may read stale data during a rolling restart or when write-commit-level-override is set to master.
Note: Aerospike may choose to read from all if the record is not found locally and the server determines there are multiple versions of the partition 6 in the cluster. For server version 3.10.1 and above, not-found on reads do not get duplicate resolved during migrations unless if explicitly enforced (through read consistency setting on client policy or server side override).
When read-consistency-level-override is all, regardless of the client’s consistency level, the server reads all out of sync copies of the data. This setting ensures that the server does not read stale data from a node which has been out of the cluster for some time.
Note: If the partitions in the cluster are all in sync and no migrations are in progress, the server only reads from a single node. Even if “read consistency level” is set to all, the server can still read stale data if the “write commit level” is set to master.
Write Consistency
If write-commit-level-override is off and it is not specified by the client, the default behavior for the server is all. It writes to all nodes containing the partitions that hold the record.
When write-commit-level-override is all, regardless of the client’s commit level, the server commits to all nodes that have a copy of the partition that holds the record.
When write-commit-level-override is set to master, regardless of the client’s commit level, the server only commits to the master partition. If it updates and then reads the same record, the client could read a previous version of the record, even if the "read consistency level is all.
More information may be found here: http://www.aerospike.com/docs/architecture/consistency.html
Notes
For strongly consistent namespaces (configured with thestrong-consistency config set to true), the read-consistency-level-override and write-commit-level-override are not available/relevant and, with default client policies, you would always read from the node owning the master copy and, if you have write transactions that are ‘in flight’, would have to wait for them.