[
https://issues.apache.org/jira/browse/CASSANDRA-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14996546#comment-14996546
]
T Jake Luciani commented on CASSANDRA-10674:
--------------------------------------------
I think the underlying issue here is streaming failures only account for
problems during the file send. Not any subsequent errors.
We should handle this by first making this mv replica lookup error not throw an
exception, but rather log a warning and force the data into the batchlog since
on replay it will force data to all replicas.
Second and more importantly we should probably add an acknowledgement to the
streaming operation that it was processed by the receiver correctly. This
could delay the decommissioning since for MV streaming that could take some
time to process. However it is safer esp in a low RF scenario.
> 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
> 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)
