Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 9 Oct 2017 20:10:00 +0000 (UTC)
From: "DOAN DuyHai (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13063582.1492021729000.10234.1507579800621@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 tunable storage requirements
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 09 Oct 2017 20:10:05 -0000


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

DOAN DuyHai commented on CASSANDRA-13442:
-----------------------------------------

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.

> 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