cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-12888) Incremental repairs broken for MVs and CDC
Date Mon, 06 Mar 2017 15:45:33 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897523#comment-15897523
] 

T Jake Luciani edited comment on CASSANDRA-12888 at 3/6/17 3:44 PM:
--------------------------------------------------------------------

Proposing another (maybe simpler solution to this problem):

We currently replay the base table mutations through the write path and drop the streamed
table.

Instead of this we could use the streamed base table with repairedAt flag like any other repair.
Then, just as we do now replay the mutations through the write path, only create a mutation
flag that only updates the MVs and not the base table. 

This means the MV wouldn't be incrementally repairable but really you shouldn't need to repair
the MVs unless there is dataloss.




was (Author: tjake):
Proposing another (maybe simpler solution to this problem):

We currently replay the base table mutations through the write path and drop the streamed
table.

Instead of this we could  keep the streamed based table with repairedAt flag and drop it in.
Then, just as we do now replay the mutations through the write path, only create a mutation
flag that only updates the MVs and not the base table. 



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

Mime
View raw message