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

Paulo Motta commented on CASSANDRA-13065:
-----------------------------------------

Thanks for the ping, I didn't get the JIRA notification for some reason. :(

bq. According to the feedback of Joshua McKenzie, I didn't add anything for 
CDC. Hope this is ok.

Right now the commit-log segment discarding is tied to memtable flushing, so 
I'm not sure how bypassing the memtable will affect commitlog segment 
discarding for mutations originated from streaming so it would be nice to have 
a test for that. Furthermore, right now there's no test for CDC behavior on 
streaming so this is a good opportunity to add a dtest verifying that behavior 
(leaving the house cleaner than you found it).

Since this may be considerable effort, I'm fine if we split the cdc component 
of this ticket into another ticket.

bq. So now you have MV data on C that belonged to a base table on A which is 
very likely to have an inconsistent relation not to it's base table data on D.

That's right, but after inconsistent range movements you are expected to run 
repair in both the base table and the view, which should make the rebuilt view 
consistent with the base again. So, in this scenario you would repair the bases 
A and D first, making them consistent, and then repair the views B and C, thus 
making base D consistent with view C.

I looked the updated patch and looks good, except the following nits:
* reuse {{requiresWritepath}} variable on before {{sendThroughWritePath}}
* no need to have a special {{UNIT_TEST}} {{StreamOperation}}, can just reuse 
one of the existing types
* I think you renamed mbean names ({{StorageProxy}}, {{StorageService}}, 
{{StreamManager}}) from {{type}} to {{streamOperation}} by mistake
* There are still a few places using {{streamOperation.toString()}} instead of 
{{streamOperation.getDescription()}}

> Consistent range movements to not require MV updates to go through write 
> paths 
> -------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13065
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13065
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benjamin Roth
>            Assignee: Benjamin Roth
>            Priority: Critical
>             Fix For: 4.0
>
>
> Booting or decommisioning nodes with MVs is unbearably slow as all streams go 
> through the regular write paths. This causes read-before-writes for every 
> mutation and during bootstrap it causes them to be sent to batchlog.
> The makes it virtually impossible to boot a new node in an acceptable amount 
> of time.
> Using the regular streaming behaviour for consistent range movements works 
> much better in this case and does not break the MV local consistency contract.
> Already tested on own cluster.
> Bootstrap case is super easy to handle, decommission case requires 
> CASSANDRA-13064



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to