cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-13442) Support a means of strongly consistent highly available replication with tunable storage requirements
Date Mon, 09 Oct 2017 19:34:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197574#comment-16197574
] 

Ariel Weisberg edited comment on CASSANDRA-13442 at 10/9/17 7:33 PM:
---------------------------------------------------------------------

bq. As far as I understand, with RF=3, if you remove repaired data on transient replicas,
you'll reduce storage by 1/3. Where do you get this 10x - 20x then ?
10-20x on transient replicas. Not at full replicas or overall. The new capability is adding
replicas without having to commit the full amount of additional hardware.

If you are running RF=3 today you might be able to switch to RF=5 with two transient replicas.
You would be able tolerate more failures and you might be able to do it without adding additional
capacity to your deployment.


was (Author: aweisberg):
bq. As far as I understand, with RF=3, if you remove repaired data on transient replicas,
you'll reduce storage by 1/3. Where do you get this 10x - 20x then ?
10-20x on transient replicas. Not at full replicas or overall. The new capability is adding
replicas without having to commit the full amount of additional hardware.

> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message