[
https://issues.apache.org/jira/browse/CASSANDRA-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15894495#comment-15894495
]
Stefan Podkowinski commented on CASSANDRA-12888:
------------------------------------------------
Before moving on in the discussion, I think [~pauloricardomg]'s suggestion
still stands and deserves some more thoughts:
bq. As discussed on the mailing list and CASSANDRA-12905 we cannot ensure view
consistency with sstable-based streaming of base/MVs in all scenarios,
specially with repair, so I'm afraid this is not a viable solution just yet
(needs to be further discussed). An alternative is to provide an option for
repair to allow repairing base and MV separately when you know what you are
doing©.
Actually having to repair both, base and view table to get back into a
consistent state, is something I would expect as a user and something that
would happen anyway during my regular repairs, whereas the mutation based
approach is probably unheard of by most users and totally unexpected, given how
we handled anti-entropy in the past. Although we talk about "views", I think
most users will understand that these are actually separate tables and should
be handled as that from a operational perspective. So do we really want to
introduce additional complexity that may bite us in the back at some point,
instead of just relying on regular repairs?
> 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.11.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.15#6346)
