[
https://issues.apache.org/jira/browse/CASSANDRA-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15737403#comment-15737403
]
Benjamin Roth commented on CASSANDRA-12888:
-------------------------------------------
HI Paulo,
Thanks for the congrats!
About your proposal to skip the base table mutations:
I haven't analyzed it thoroughly (no time, you know) but my intuition says that
there will be race conditions and possible inconsistencies as you "pick out"
the base table mutation out of the lock phase. I guess to assert the base table
<> view replica consistency you'd have to lock the whole CF while streaming a
single SSTable to assert that the MV mutations are processed serial and no
other base table mutations slip in from the mutation stage that mess with the
consistency.
As far as i can see, base table apply, base-read and MV mutations MUST be
serialized (actually that's why there's a lock). Otherwise you will have stale
MV rows again. This is why I think this proposal won't work. Or did I miss the
point?
CDC:
This case should be quite simple. I think you don't need the write path at all
and just have to write the incoming mutations to commit log additionally to
streaming the sstable. In the worst case, server crashed, commit log replay
leads to redundant and unrepaired entries but this should be a rare and
recoverable situation.
What do you think?
> Incremental repairs broken for MVs and CDC
> ------------------------------------------
>
> Key: CASSANDRA-12888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12888
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Reporter: Stefan Podkowinski
> Assignee: Benjamin Roth
> Priority: Critical
> Fix For: 3.0.x, 3.x
>
>
> SSTables streamed during the repair process will first be written locally and
> afterwards either simply added to the pool of existing sstables or, in case
> of existing MVs or active CDC, replayed on mutation basis:
> As described in {{StreamReceiveTask.OnCompletionRunnable}}:
> {quote}
> We have a special path for views and for CDC.
> For views, since the view requires cleaning up any pre-existing state, we
> must put all partitions through the same write path as normal mutations. This
> also ensures any 2is are also updated.
> For CDC-enabled tables, we want to ensure that the mutations are run through
> the CommitLog so they can be archived by the CDC process on discard.
> {quote}
> Using the regular write path turns out to be an issue for incremental
> repairs, as we loose the {{repaired_at}} state in the process. Eventually the
> streamed rows will end up in the unrepaired set, in contrast to the rows on
> the sender site moved to the repaired set. The next repair run will stream
> the same data back again, causing rows to bounce on and on between nodes on
> each repair.
> See linked dtest on steps to reproduce. An example for reproducing this
> manually using ccm can be found
> [here|https://gist.github.com/spodkowinski/2d8e0408516609c7ae701f2bf1e515e8]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
