[jira] [Created] (CASSANDRA-13073) Optimize repair behaviour with MVs

["Benjamin Roth (JIRA)" <ji...@apache.org>]

Benjamin Roth created CASSANDRA-13073:
-----------------------------------------

             Summary: Optimize repair behaviour with MVs
                 Key: CASSANDRA-13073
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13073
             Project: Cassandra
          Issue Type: Bug
            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.3.4#6332)