[
https://issues.apache.org/jira/browse/CASSANDRA-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035931#comment-15035931
]
Carl Yeksigian commented on CASSANDRA-10674:
--------------------------------------------
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 [~jkni]'s Jepsen testing.
Because we aren't storing any values for the base table as part of the batch,
replaying the view mutations once we are no longer a pending endpoint won't
change the values that we are trying to push to the view replicas. For that
reason, the batchlog that we write should be cleaned up once we have pushed the
values out 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)