[
https://issues.apache.org/jira/browse/CASSANDRA-6887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012367#comment-14012367
]
Sylvain Lebresne commented on CASSANDRA-6887:
---------------------------------------------
bq. Relying on on dc/global read repair chance now, however, is not the most
logical/expected behavior and violates the principle of least surprise.
Again, I do think we should change the default because I agree the current
default violates the principle of least surprise. But I disagree that crippling
Cassandra by making it impossible to have global read repair with LOCAL CL
helps in any way. Unless we have a strong reason to do it, but I don't think
that's the case.
bq. LOCAL_* requests will potentially use a replica from another DC for an
eager retry
I can agree that it's a problem. But surely that can easily be fixed separately
from the rest.
bq. All three of RRD.NONE/GLOBAL/DC_LOCAL can cause a request go to a different
DC for LOCAL_* CL queries, depending on the # of live replicas in the local DC
I don't think that's true. For RDD.NONE/DC_LOCAL, CL.filterForQuery will only
include non-local nodes if the number of live local nodes is < blockFor. But in
that case CL.assureSufficientLiveNodes will throw an UnavailableException.
bq. So I still think that LOCAL_* CLs should not allow any aspect of the query
to involve a non-local DC - that's arguably the whole point of LOCAL_* CLs
I don't entirely agree. The point of LOCAL_* CLs is to get proper latencies in
multi-DC setups. There is nothing wrong with having having asynchronous
read-repair across DCs when you use them. In fact, that might even be a good
idea.
bq. 3. A user might not want to have read_repair_chance set to 0 entirely, and
also use both LOCAL_* and regular consistency levels - on per-query basis.
Theoretically, you're correct. But in my experience, if you have multi-DC
setup, you'll always want you queries to be LOCAL_* (except maybe for a few
maintenance queries where you want to ensure across-DC consistency, but they're
probably not live queries and you probably don't care about read-repair on
those). I think the scenario "I want to do only LOCAL CL queries but I'd like
to do cross-DC read-repair asynchronously for 1% of my queries (and maybe
dc-local read-repair for 10% of them)" is much more useful and common than some
weird case where you mix local and non-local CL on the same table while still
caring about read-repair.
> LOCAL_ONE read repair only does local repair, in spite of global digest
> queries
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-6887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6887
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.0.6, x86-64 ubuntu precise
> Reporter: Duncan Sands
> Assignee: Aleksey Yeschenko
> Fix For: 2.0.9, 2.1 rc1
>
> Attachments: 6887-2.0.txt
>
>
> I have a cluster spanning two data centres. Almost all of the writing (and a
> lot of reading) is done in DC1. DC2 is used for running the occasional
> analytics query. Reads in both data centres use LOCAL_ONE. Read repair
> settings are set to the defaults on all column families.
> I had a long network outage between the data centres; it lasted longer than
> the hints window, so after it was over DC2 didn't have the latest
> information. Even after reading data many many times in DC2, the returned
> data was still out of date: read repair was not correcting it.
> I then investigated using cqlsh in DC2, with tracing on.
> What I saw was:
> - with consistency ONE, after about 10 read requests a digest request would
> be sent to many nodes (spanning both data centres), and the data in DC2 would
> be repaired.
> - with consistency LOCAL_ONE, after about 10 read requests a digest request
> would be sent to many nodes (spanning both data centres), but the data in DC2
> would not be repaired. This is in spite of digest requests being sent to
> DC1, as shown by the tracing.
> So it looks like digest requests are being sent to both data centres, but
> replies from outside the local data centre are ignored when using LOCAL_ONE.
> The same data is being queried all the time in DC1 with consistency
> LOCAL_ONE, but this didn't result in the data in DC2 being read repaired
> either. This is a slightly different case to what I described above: in that
> case the local node was out of date and the remote node had the latest data,
> while here it is the other way round.
> It could be argued that you don't want cross data centre read repair when
> using LOCAL_ONE. But then why bother sending cross data centre digest
> requests? And if only doing local read repair is how it is supposed to work
> then it would be good to document this somewhere.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
