[
https://issues.apache.org/jira/browse/CASSANDRA-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079995#comment-14079995
]
Jeremiah Jordan commented on CASSANDRA-7642:
--------------------------------------------
If users want different logic than DowngradingConsistencyRetryPolicy, then put
it in DowngradingConsistencyRetryPolicyPlusPlus or a user can implement their
own crazy retry policy by writing there own, all of the drivers support
pluggable retry policies from user code.
Supporting this server side is ONLY of help in the case of a "Timeout" where
maybe we got back 2 out of required 3 responses, and the MIN says 2 is OK. But
again, if 2 is OK, then just query with 2 from the beginning.
Writes always go to all nodes regardless of CL specified, so "how many nodes do
I wait to hear back from" should be the CL you pick, down grading you can
silently lose out on a consistency you expect. You also need a way to notify
the client that you downgraded, and for the client to react to that if you want
to do this with any chance of not having unexpected results. So you might as
well just have full control from the client/driver to start.
For reads if the issue is unavailability, you get that response back real
quick. If the issue is something timing out, the rapid retry logic will try
another node for you already. So if you want consistency read at QUORUM. And
again, if you are OK with reading at ONE, then just read at ONE. In the case
where you really really want to read at QUORUM if you can and then switch to
ONE, again you want to have full control and knowledge of that from your
application, or else you WILL have unexpected things happen.
People tell me they want to do this all the time, and when I ask them WHY they
want to do it, once it is explained to them the consequences of what they want
to do are, they decide they don't actually want this. I have never seen
DowngradingConsistencyRetryPolicy actually be what someone wants.
Now an "UpgradingConsistencyRetryPolicy" when you don't get back an answer you
expect to get, that is useful. But again really needs to be controlled from
the application side. I have used this to good effect before where reads and
writes both default to ONE, and there are cases where the client application
knows to expect data, but doesn't get it, so you can try again at QUORUM/ALL to
get the data. Again not something that can be easily done server side, as it
requires client application knowledge of when this type of retry is needed.
> Adaptive Consistency
> --------------------
>
> Key: CASSANDRA-7642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7642
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Rustam Aliyev
> Fix For: 3.0
>
>
> h4. Problem
> At minimum, application requires consistency level of X, which must be fault
> tolerant CL. However, when there is no failure it would be advantageous to
> use stronger consistency Y (Y>X).
> h4. Suggestion
> Application defines minimum (X) and maximum (Y) consistency levels. C* can
> apply adaptive consistency logic to use Y whenever possible and downgrade to
> X when failure occurs.
> Implementation should not negatively impact performance. Therefore, state has
> to be maintained globally (not per request).
> h4. Example
> {{MIN_CL=LOCAL_QUORUM}}
> {{MAX_CL=EACH_QUORUM}}
> h4. Use Case
> Consider a case where user wants to maximize their uptime and consistency.
> They designing a system using C* where transactions are read/written with
> LOCAL_QUORUM and distributed across 2 DCs. Occasional inconsistencies between
> DCs can be tolerated. R/W with LOCAL_QUORUM is satisfactory in most of the
> cases.
> Application requires new transactions to be read back right after they were
> generated. Write and read could be done through different DCs (no
> stickiness). In some cases when user writes into DC1 and reads immediately
> from DC2, replication delay may cause problems. Transaction won't show up on
> read in DC2, user will retry and create duplicate transaction. Occasional
> duplicates are fine and the goal is to minimize number of dups.
> Therefore, we want to perform writes with stronger consistency (EACH_QUORUM)
> whenever possible without compromising on availability. Using adaptive
> consistency they should be able to define:
> {{Read CL = LOCAL_QUORUM}}
> {{Write CL = ADAPTIVE (MIN:LOCAL_QUORUM, MAX:EACH_QUORUM)}}
> Similar scenario can be described for {{Write CL = ADAPTIVE (MIN:QUORUM,
> MAX:ALL)}} case.
> h4. Criticism
> # This functionality can/should be implemented by user himself.
> bq. It will be hard for an average user to implement topology monitoring and
> state machine. Moreover, this is a pattern which repeats.
> # Transparent downgrading violates the CL contract, and that contract
> considered be just about the most important element of Cassandra's runtime
> behavior.
> bq.Fully transparent downgrading without any contract is dangerous. However,
> would it be problem if we specify explicitly only two discrete CL levels -
> MIN_CL and MAX_CL?
> # If you have split brain DCs (partitioned in CAP), you have to sacrifice
> either consistency or availability, and auto downgrading sacrifices the
> consistency in dangerous ways if the application isn't designed to handle it.
> And if the application is designed to handle it, then it should be able to
> handle it in normal circumstances, not just degraded/extraordinary ones.
> bq. Agreed. Application should be designed for MIN_CL. In that case, MAX_CL
> will not be causing much harm, only adding flexibility.
> # It might be a better idea to loudly downgrade, instead of silently
> downgrading, meaning that the client code does an explicit retry with lower
> consistency on failure and takes some other kind of action to attempt to
> inform either users or operators of the problem. The silent part of the
> downgrading which could be dangerous.
> bq. There are certainly cases where user should be informed when consistency
> changes in order to perform custom action. For this purpose we could
> allow/require user to register callback function which will be triggered when
> consistency level changes. Best practices could be enforced by requiring
> callback.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
