Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 18 Apr 2017 03:13:41 +0000 (UTC)
From: "sankalp kohli (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13063582.1492021729000.302096.1492485221689@Atlassian.JIRA>
In-Reply-To: <JIRA.13063582.1492021729000@Atlassian.JIRA>
References: <JIRA.13063582.1492021729000@Atlassian.JIRA> <JIRA.13063582.1492021729699@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13442) Support a means of strongly
 consistent highly available replication with storage requirements
 approximating RF=2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 18 Apr 2017 03:13:46 -0000


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

sankalp kohli commented on CASSANDRA-13442:
-------------------------------------------

[~tjake]  We need to make changes to bootstrap and other operations to know about this. 
This will also involve changes in the resolver to know which is full replica vs partial replica and make best use of that. 

> Support a means of strongly consistent highly available replication with storage requirements approximating RF=2
> ----------------------------------------------------------------------------------------------------------------
>
>                 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.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)