Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 6 Jun 2017 11:46:18 +0000 (UTC)
From: "Sergio Bossa (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12857283.1440006050000.4874.1496749578574@Atlassian.JIRA>
In-Reply-To: <JIRA.12857283.1440006050000@Atlassian.JIRA>
References: <JIRA.12857283.1440006050000@Atlassian.JIRA> <JIRA.12857283.1440006050745@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-10130) Node failure during 2i update
 after streaming can have incomplete 2i when restarted
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 06 Jun 2017 11:46:24 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-10130?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D16038692#comment-16038692 ]=20

Sergio Bossa commented on CASSANDRA-10130:
------------------------------------------

bq. Sorry for being picky here but while we are fixing the original limitat=
ion, we are introducing a new limitation that if there's ever a non-fatal i=
ndex build failure, a successful full index rebuild will not mark the index=
 as built until the node is restarted and the index is unnecessarily rebuil=
t.

Excellent point, you're not being picky at all. There's actually a related =
problem: if a single sstable indexing fails, we restart the node, and try t=
o load a *new* sstable, the index will be marked as built, even if there's =
an sstable whose indexing failed.

In other words, it seems to me we should mark the index as built _only_ if:
1) It is a full rebuild.
2) It is an initialization task (which should be considered as the initial =
full build).
3) It is a single/group sstable(s) indexing, and the index was *already bui=
lt*: that is, if we initiate an sstable indexing, but the index was *not* m=
arked as built, we should preserve such state (that implementation-wise pro=
bably means to just keep the counters at 0 and avoid any marking).

Other than that, I have a concern about [flushing indexes in the future tra=
nsformation|https://github.com/apache/cassandra/compare/trunk...adelapena:1=
0130-trunk#diff-3f2c8994c4ff8748c3faf7e70958520dR399], which would cause su=
ch blocking activity to happen in the compaction thread, a departure from p=
revious behaviour and probably an unwanted one.

> Node failure during 2i update after streaming can have incomplete 2i when=
 restarted
> -------------------------------------------------------------------------=
----------
>
>                 Key: CASSANDRA-10130
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1013=
0
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Coordination
>            Reporter: Yuki Morishita
>            Assignee: Andr=C3=A9s de la Pe=C3=B1a
>            Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure duri=
ng MV/2i update can leave received SSTables live when restarted while MV/2i=
 are partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at th=
e startup, or at least warn user when the node restarts.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org