I am planning to use Aerospike, in which Strong consistrncy is requried. I wanted to know what will be the effect of String Consistency (i.e. Synchronous Replication) on Availability?
For replication-factor 2 and sequential consistency, the performance is equivalent to AP mode. There are impacts for higher replication, linearization, or commit-to-device.
1 Like
I hope you don’t mind that I quote part of your deleted reply:
My main aim is to ensure that after INSERT/UPDATE, the data shouldbeconsistent for all reads.
This would indicate that your use case requires linearizability. Normally this isn’t actually true for all reads and in Aerospike you can specify which reads need to be linearized. Often, we have also found that it isn’t actually required for any read. Sequential (aka session) consistency means that a particular session is guaranteed to see a linear progressions of updates but the progression across all sessions may not be linear. Sequential consistency in Aerospike will actually provide linear progression across all sessions in the absence of any disruptions to the cluster. However; disruptions are unavoidable, but only account for a very small fraction of the clusters overall operation time. These disruptions come in the form of (non-quiesced) maintenance windows or unexpected network/node failures and only in these disruptions can the client potentially have a burst of non-linearized reads when using Sequential consistency. Additionally, the maintenance window case can be eliminated if the quiesce command is used on the Aerospike nodes and clients are allowed to transition from the quiesced nodes before the nodes are stopped.
In general, if a non-linearized read is some degree of inconvenient and not a serious risk to the application then you probably should use Sequential consistency. Consider the trade-offs carefully.
1 Like
How about we use replication-factor 2, COMMIT_ALL write policy and Replica read policy as MASTER_PROLES? How will this impact Availability?
These are AP settings and don’t apply to Strong Consistency, SC has a slightly different set of policies that it must follow. The writes will be commit all and the reads will need to resolve against all unique partition copies. In normal running conditions where all migrations are complete, only one node is read.
replication-factor 2 allows one node to fail for a particular partition and the partition to still be live. You can enhance availability by using rack-aware.
1 Like
What kind of Policies ? Can you help me identifying those policies 
Basically these are rules that are enabled and cannot be disabled when strong-consistency is configured. Basically the SC policy behaves similar to read-consistency-level-override all and write-commit-level-override all. But not exactly these, certain errors have to be handled differently in SC and there is a concept of a cluster “regime” and the rules around it. You can find more information about these in the strong-consistency docs.