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

Paulo Motta commented on CASSANDRA-10674:
-----------------------------------------

bq. Originally, if the local node was not a replica of the base mutation, 
getViewNaturalEndpoints would throw an exception, so much of this has been 
added because of Joel Knighton's Jepsen testing.

If this scenario happens (the local node is not a replica of the base 
mutation), I suppose we should we should skip the 
{{asyncWriteBatchedMutations}} call and write only to the batchlog in the hope 
that this node will later be able to find a natural replica of that view?

bq. For that reason, the batchlog that we write should be cleaned up once we 
have pushed the values out to the view replicas.

Got it. Regardless of pending endpoints, we should always clear the batch if 
we're able to write to the view replicas.

> Materialized View SSTable streaming/leaving status race on decommission
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-10674
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10674
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Coordination, Distributed Metadata
>            Reporter: Joel Knighton
>            Assignee: Paulo Motta
>             Fix For: 3.0.1, 3.1
>
>         Attachments: leaving-node-debug.log, receiving-node-debug.log
>
>
> On decommission of a node in a cluster with materialized views, it is 
> possible for the decommissioning node to begin streaming sstables for an MV 
> base table before the receiving node is aware of the leaving status.
> The materialized view base/view replica pairing checks pending endpoints to 
> handle the case when an sstable is received from a leaving node; without the 
> leaving message, this check breaks and an exception is thrown. The streamed 
> sstable is never applied.
> Logs from a decommissioning node and a node receiving such a stream are 
> attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to