[
https://issues.apache.org/jira/browse/CASSANDRA-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197649#comment-16197649
]
Ariel Weisberg edited comment on CASSANDRA-13442 at 10/9/17 8:28 PM:
---------------------------------------------------------------------
bq. I did not mean about end-users, I meant about core C* developers. We need
to introduce some code change in order to accomodate the asymmetry between
replicas in the code base.
I agree. I don't think that's something we can quantify until someone submits a
patch with unit and integration tests so we can weigh the cost against the
measured gains and tradeoffs of a real implementation.
Some of it might end up being part of overlapping functionality. I can hope.
was (Author: aweisberg):
bq. I did not mean about end-users, I meant about core C* developers. We need
to introduce some code change in order to accomodate the asymmetry between
replicas in the code base.
I agree. I don't think that's something we can quantify until someone submits a
patch with unit and integration tests so we can weight the cost against the
measured gains and tradeoffs of a real implementation.
Some of it might end up being part of overlapping functionality. I can hope.
> Support a means of strongly consistent highly available replication with
> tunable storage requirements
> -----------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-13442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13442
> Project: Cassandra
> Issue Type: Improvement
> Components: Compaction, Coordination, Distributed Metadata, Local
> Write-Read Paths
> Reporter: Ariel Weisberg
>
> Replication factors like RF=2 can't provide strong consistency and
> availability because if a single node is lost it's impossible to reach a
> quorum of replicas. Stepping up to RF=3 will allow you to lose a node and
> still achieve quorum for reads and writes, but requires committing additional
> storage.
> The requirement of a quorum for writes/reads doesn't seem to be something
> that can be relaxed without additional constraints on queries, but it seems
> like it should be possible to relax the requirement that 3 full copies of the
> entire data set are kept. What is actually required is a covering data set
> for the range and we should be able to achieve a covering data set and high
> availability without having three full copies.
> After a repair we know that some subset of the data set is fully replicated.
> At that point we don't have to read from a quorum of nodes for the repaired
> data. It is sufficient to read from a single node for the repaired data and a
> quorum of nodes for the unrepaired data.
> One way to exploit this would be to have N replicas, say the last N replicas
> (where N varies with RF) in the preference list, delete all repaired data
> after a repair completes. Subsequent quorum reads will be able to retrieve
> the repaired data from any of the two full replicas and the unrepaired data
> from a quorum read of any replica including the "transient" replicas.
> Configuration for something like this in NTS might be something similar to {
> DC1="3-1", DC2="3-2" } where the first value is the replication factor used
> for consistency and the second values is the number of transient replicas. If
> you specify { DC1=3, DC2=3 } then the number of transient replicas defaults
> to 0 and you get the same behavior you have today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
