On Thu, Jun 16, 2011 at 8:18 AM, AJ <a...@dude.podzone.net> wrote: > Good morning all. > > Hypothetical Setup: > 1 data center > RF = 3 > Total nodes > 3 > > Problem: > Suppose I need maximum consistency for one critical operation; thus I > specify CL = ALL for reads. However, this will fail if only 1 replica > endpoint is down. I don't see why this fail is necessary all of the time > since the data could have been updated since the node became unavailable and > it's data is old anyways. If only one node goes down and it has the key I > need, then the app is not 100% available and it could take some time making > the node available again. > > Proposal: > If all of the *available* replica nodes answer the read operation and the > latest value timestamp is clearly AFTER the time the down node became > unavailable, then this situation can meet the requirements for *near* 100% > consistency since the value in the down node would be outdated anyway. > Clearly, the value was updated some time *after* the node went down or > unavailable. This way, you can have max availability when using read with > CL.ALL... or something CL close in meaning to ALL. > > I say "near" 100% consistency to leave room for some situation where the > unavailable node was only unavailable to the coordinating node for some > reason such as a network issue and thus still received an update by some > other route after it "appeared" unavailable to the current coordinating > node. In a situation like this, there is a chance the read will still not > return the latest value. So, this will not be truly 100% consistent which > CL.ALL guarantees. However, I think this logic could justify a new > consistency level slightly lower than ALL, such as ALL_AVAIL. > > What do you think? Is my logic correct? Is there a conflict with the > architecture or base principles? This fits with the tunable consistency > principle for sure.
I don't think this buys you anything that you can't get with quorum reads and writes. -ryan
