[
https://issues.apache.org/jira/browse/CASSANDRA-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370974#comment-14370974
]
Sylvain Lebresne commented on CASSANDRA-8989:
---------------------------------------------
bq. As a workaround you can reduce the read repair chances in that table's
parameters.
It probably won't help. Since the request is a CL > ONE, the "read repair" they
are seeing is probably not due to "read_repair_chance" kicking in, but rather
to the read-repair from normal reconciliation (which cannot be de-activated).
I'll also note that this is not specific to collections, any range tombstone
would trigger that, include normal row deletions (since they generate a range
tombstone). It's just true that collections tends to create more range
tombstones that other stuffs.
Now, regarding CASSANDRA-6863, it's old enough that I don't remember the exact
circumstances, but I suspect the worry about upgrade was due to the fact that
the patch started including range tombstones in digests and we feared that this
would trigger a digest mismatch hell during upgrade. However, we could backport
the patch from CASSANDRA-6863 patch without the digest changes. That is, we'd
include only the diffing of RT so that when we do get full data responses (and
remember than on range slices we never asks digests in the first place) we at
least don't send RT uselessly if all nodes are actually in sync.
> Reading from table which contains collection type using token function and
> with CL > ONE causes overwhelming writes to replicas
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-8989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8989
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Miroslaw Partyka
> Assignee: Carl Yeksigian
> Priority: Critical
> Attachments: trace.txt
>
>
> When reading from a table at the aforementioned conditions, each read from
> replica also casues write to the replica.
> Confimed in version 2.0.12 & 2.0.13, version 2.1.3 seems ok.
> To reproduce:
> {code}CREATE KEYSPACE test WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC1': 2};
> USE test;
> CREATE TABLE bug(id int PRIMARY KEY, val map<int,int>);
> INSERT INTO bug(id, val) VALUES (1, {2: 3});
> CONSISTENCY LOCAL_QUORUM
> TRACING ON
> SELECT * FROM bug WHERE token(id) <= 0;{code}
> trace contains twice:
> Appending to commitlog
> Adding to bug memtable
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
