Thanks for clarifying this Rob. -However no step other than 2) provides a *guarantee* of consistency. And it only provides that guarantee for data that exists when the repair starts.
I read the above as "consistency is a strong term..." :) But that's understandable. Thanks again for your help. On Tue, Oct 27, 2015 at 10:49 PM, Robert Coli <rc...@eventbrite.com> wrote: > On Sat, Oct 24, 2015 at 2:02 PM, Vasileios Vlachos < > vasileiosvlac...@gmail.com> wrote: > >> >>> All other means of repair are optimizations which require a certain >>> amount of luck to happen to result in consistency. >>> >> >> Is that true regardless of the CL one uses? So, for example if writing >> QUORUM and reading QUORUM, wouldn't an increased read_repair_chance >> probability be sufficient? If not, is there a case where nodetool repair >> wouldn't be required (given consistency is a requirement)? >> > > The only thing which guarantees consistency[1] is repair. > > It's likely true that if the following conditions are met : > > 1) you read and write with QUORUM or ALL > 2) you repair periodically > 3) you have not dropped any mutations or had a crashed node since you last > repaired > 4) you have not discarded any hints which happened to be stored for > whatever reason > 5) you have not failed to store any hints due to hint backpressure > > That you have a system with the property of consistency. > > However no step other than 2) provides a *guarantee* of consistency. And > it only provides that guarantee for data that exists when the repair starts. > > In a related concept, no step other than 2) *guarantees* that all data is > repaired within gc_grace_seconds, which is essential to consistency. > > =Rob > [1] Durability and consistency are commingled in Cassandra, you are more > likely to fully achieve the former than the latter in the typical RF=3 case. >
