[
https://issues.apache.org/jira/browse/CASSANDRA-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16581234#comment-16581234
]
Blake Eggleston commented on CASSANDRA-10726:
---------------------------------------------
Review changes pushed to branch with a few exceptions.
[~krummas], for {{BlockingPartitionRepair#isLocal}}and
{{BlockingPartitionRepair#sendRR}}, these methods are both used in
{{ReadRepairTestInstrumentedReadRepairHandler}} for testing.
[~ifesdjeen]:
bq. We might want to simplify the code a little by not caching versions here.
I'd really prefer to leave as is if it's ok with you. It's not that
complicated, and we avoid re-calculating mutation size for every endpoint we
send a repair mutation to, which could be fairly regularly for higher rf
keyspaces.
bq. Partition range code path is also affected (since StorageProxy#fetchRows is
changed). It'd be great to have dtests for partition ranges as well.
fetchRows only processes SinglePartitionReadCommands (although it can process
multiple from {{SELECT WHERE <primary key> IN (...)}} queries). Partition range
reads are handled elsewhere, and don't support speculation in the normal or
read repair path. They are affected by the read repair refactor, but are
already tested with existing dtests.
> Read repair inserts should not be blocking
> ------------------------------------------
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
> Reporter: Richard Low
> Assignee: Blake Eggleston
> Priority: Major
> Fix For: 4.x
>
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert
> to update out of date replicas is blocking. This means, if it fails, the read
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or
> the mutation stage is backed up for some other reason), all reads to a
> replica set could fail. Further, replicas dropping writes get more out of
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not
> be blocking or we should return success for the read even if the write times
> out.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
