Originally from the User Slack
@Daria_Fedorova: Hi I want to ask some questions about Consistency Level (CL)
Does it affect anything except what scylla returns to client ? If CL for write was not reached , will coordinator try to rollback the operation or mark it as failed to be repaired in accordance with what we returned to client ?
Will repair be affected by CL ? For example if write requests CL=ALL and it failed but most of the nodes succeeded, Will repair know that operation overall failed and roll it back or will it try to add this write on rest of the nodes ?
The question arose when I found DowngradingConsistencyRetryPolicy
If CL only affects the answer to client then it seems to me that there is no use in retrying with lower CL , if lower CL is acceptable for a client it can set lower CL from the beginning.
@Felipe_Cardeneti_Mendes: There’s no rollback.
The idea is that your client must retry as it receives an exception.
@Daria_Fedorova: so repair will repair to quorum value ?
@Felipe_Cardeneti_Mendes: repair will sync all replicas. For example, if you write n=1 with Quorum and this write gets accepted to one out of three replicas, you will receive an exception.
Considering you did nothing and “let it go”, later - as you repair, n=1 will be propagated to the remaining 2 replicas which missed the write.
also see hinted handoff and read repair, other anti-entropy mechanisms.
@Daria_Fedorova: Thanks I will read it too
This leaves the question - what is DowngradingConsistencyRetryPolicy used for ?
Is it legacy ? why would a client need to rerty with lower CL if first request failed
• if first request reached lower CL write will be propagated eventually
Is it a way to effectually use lower CL but still monitor errors with high CL. ?
@Felipe_Cardeneti_Mendes: In general this is down to application semantics. Some apps are fine with a lower consistency level momentarily, others aren’t.
Imagine you lose quorum for whatever reason. In this situation, you’d have 2 nodes down (considering RF=3).
If this is fine, then Downgrading the consistency would allow you to continue serving traffic with a lower consistency, given that only a single replica is available.
Some apps can’t tolerate even that, because there’s no way to guarantee that just because 1 replica is available that it has all the data the other 2 had. So at this point, even though you are still operating fine, you are ok with serving stale data.
@Karol_Baryła: I may be misremembering, but I think DowngradingConsistencyRetryPolicy is actually deprecated in Java Driver 3.x or 4.x (don’t remember which one)
@Felipe_Cardeneti_Mendes: V4