cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13442) Support a means of strongly consistent highly available replication with storage requirements approximating RF=2
Date Tue, 18 Apr 2017 02:56:41 GMT


Jonathan Ellis commented on CASSANDRA-13442:

Man, this makes me really nervous.  Reducing replication automagically is ripping the safety
guard off a chainsaw and handing it to a ten year old.  Remember that those replicas aren't
just for consistency but in case your hardware fails: if you have three copies and you lose
one, no big deal, you still have two to restore from.  Just two copies?  If anything goes
wrong with that other copy while you repair you are SOL.

Optimizing away redundant queries a la 7168?  Sign me up.  But I think removing that "redundant"
data and making RF not actually mean RF is going too far.

> The topology of the cluster would also have a new dimension that the drivers would need
to consider. Since for CL.ONE queries you would need to only use one of the replicas with
all the data on it.

Yes, I think there are going to be multiple places where this gets more complicated than it
looks at first.

> Support a means of strongly consistent highly available replication with storage requirements
approximating RF=2
> ----------------------------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-13442
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Compaction, Coordination, Distributed Metadata, Local Write-Read
>            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
> 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"

This message was sent by Atlassian JIRA

View raw message