cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13069) Local batchlog for MV may not be correctly written on node movements
Date Mon, 11 Sep 2017 10:00:17 GMT


Sylvain Lebresne commented on CASSANDRA-13069:

What I had in mind was more about simplifying the whole view write patch to be 1) write a
batchlog for local+view mutations and then 2) apply those mutations, which implied rewriting
{{Keyspace.apply}} so we don't start by writing the base mutation in the commit log for instance,
and I still think it would be both simpler code-wise and be more easy to reason about correction.
But this is admittedly not the place to debate about this, and you are right that things aren't
as grim as I portrayed it in my previous comment anyway, so happy to focus on just the bug
for which this was opened for.

So things mostly look good except for the {{isFirstReplay}} addition in {{BatchLogManager}}
that I'm fairly unsure about. My understanding is that the main goal of the batchlog delay
is to avoid replaying batches that may still have a change to succeed, but your change seems
to break that, so it sounds like that could have adverse performance effect, including on
non-view usages of the batchlog. To be honest though, the batchlog code isn't my main area
of expertise, so if if you feel this is important and not a real problem, I'd prefer we isolate
that change to a separate ticket so it is looked in its own right (and preferably by someone
more knowledgeable of that code).

> Local batchlog for MV may not be correctly written on node movements
> --------------------------------------------------------------------
>                 Key: CASSANDRA-13069
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Materialized Views
>            Reporter: Sylvain Lebresne
>            Assignee: Paulo Motta
> Unless I'm really reading this wrong, I think the code [here|],
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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message