Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sun, 23 Jul 2017 15:19:00 +0000 (UTC)
From: "ZhaoYang (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13030064.1482401481000.311014.1500823140150@Atlassian.JIRA>
In-Reply-To: <JIRA.13030064.1482401481000@Atlassian.JIRA>
References: <JIRA.13030064.1482401481000@Atlassian.JIRA> <JIRA.13030064.1482401481507@jira-lw-us.apache.org>
Subject: [jira] [Updated] (CASSANDRA-13073) Optimize repair behaviour with
 MVs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 23 Jul 2017 15:19:04 -0000


     [ https://issues.apache.org/jira/browse/CASSANDRA-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ZhaoYang updated CASSANDRA-13073:
---------------------------------
    Component/s: Materialized Views

> Optimize repair behaviour with MVs
> ----------------------------------
>
>                 Key: CASSANDRA-13073
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13073
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Materialized Views
>            Reporter: Benjamin Roth
>
> I am referring to a discusson on the dev list about the MV streaming issues discussed in 12888.
> It turned out that under some circumstances, repairing MVs can lead to inconsistencies. To remove that inconsistencies, it is necessary, to repair the base table first and then the MV again. These inconsistencies can be created both by read repair or CF/Keyspace repair.
> Proposition:
> - Exclude MVs from keyspace repairs
> - Disable read repairs on MVs or transform them to a read repair of the base table (maybe complicated but possible)
> Explanation:
> - CF base has PK a and field b
> - MV has PK a, b
> - 2 nodes n1 + n2, no hints
> - Initial state is a=1,b=1 at time t=0
> - Node n2 goes down
> - Mutation a=1, b=2 at time t=1
> - Node n2 comes up and node n1 goes down
> - Mutation a=1, b=3 at time t=2
> - Node n1.mv contains: a1=1, b=3 + tombstone for a1=1,b=1
> - Node n2.mv contains: a1=1, b=2 + tombstone for a1=1,b=1
> When doing a repair on mv _before_ repairing base, mv would look like:
> - Node n1.mv contains: a1=1, b=3 + tombstone for a1=1,b=1 + a1=1, b=2
> - Node n2.mv contains: a1=1, b=2 + tombstone for a1=1,b=1 + a1=1, b=3
> Repairing _only_ the base table would create the correct result:
> - Node n1.mv contains: a1=1, b=3 + tombstone for a1=1,b=1 + tombstone for a1=1,b=2
> - Node n2.mv contains: a1=1, b=3 + tombstone for a1=1,b=1 (TS for a1=2,b=2 should not have been created as b=3 was there, which shadows b=2 and should not reach the MV at all)
> All this does not apply if CASSANDRA-13066 will be implemented and enabled


--
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