[CASSANDRA-13073] Optimize repair behaviour with MVs

• Type: Bug
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Component/s: Feature/Materialized Views
• Severity: Normal
• Assignee: Unassigned
• Reporter: Benjamin Roth
• Created: 22/Dec/16 10:11
• Updated: 16/Apr/19 09:30

Description

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