[
https://issues.apache.org/jira/browse/CASSANDRA-13069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857905#comment-15857905
]
Sylvain Lebresne commented on CASSANDRA-13069:
----------------------------------------------
The patch looks good (though please add braces after the {{if
((pairedEndpoint.get().equals(...))}}) in that it fixes the issue mentioned in
the description, and I agree not decrementing the cleanup on local mutations
was wrong. But I'm honestly a bit confused about our use of the (local)
batchlog for MVs and I don't think it's right.
As far as I can tell, the goal of using a local batchlog is to guarantee
eventual consistency of a the base table and its views. That is, no matter what
happens for a given update, either both that update and all the related view
updates get eventually applied, or none of it is. But unless I'm missing
something subtle (for which there is no comment in the code), the batchlog will
only guarantees that if _all_ mutations are grouped in it. So I don't
understand why:
# we don't include local view mutations in the batchlog in {{SP.mutateMV}}.
# the base table mutation isn't included in said batchlog alongside it's
related view updates.
I'll note that fixing the first point in {{mutateMV}} would actually simplify
the method and If I'm not completely wrong here I suggest we at least do that
on this ticket. It still won't solve the 2nd point, but that's arguably more
involved so I'm ok creating a follow-up ticket for that (still, it kind of
breaks the one basic guarantee MVs are supposed to provide, so it's kind of
critical).
> Local batchlog for MV may not be correctly written on node movements
> --------------------------------------------------------------------
>
> Key: CASSANDRA-13069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13069
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Paulo Motta
>
> Unless I'm really reading this wrong, I think the code
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageProxy.java#L829-L843],
> which comes from CASSANDRA-10674, isn't working properly.
> More precisely, I believe we can have both paired and unpaired mutations, so
> that both {{if}} can be taken, but if that's the case, the 2nd write to the
> batchlog will basically overwrite (remove) the batchlog write of the 1st
> {{if}} and I don't think that's the intention. In practice, this means
> "paired" mutation won't be in the batchlog, which mean they won't be replayed
> at all if they fail.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
