cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted
Date Fri, 02 Jun 2017 03:55:05 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034094#comment-16034094
] 

Paulo Motta edited comment on CASSANDRA-10130 at 6/2/17 3:54 AM:
-----------------------------------------------------------------

bq. There's still a slight chance that an index is created between an SSTableBeforeAddedNotification
and SSTableAddedNotification and we won't have marked it as building, so we should probably
save the indexes we have marked as building when receiving the SSTableBeforeAddedNotification
and mark any new index as building after receiving an SSTableBeforeAddedNotification but before
building all indexes, and maybe extend the previous unit test to test this unlikely scenario.

The suggestion above feels a bit ugly, so this made me think that when loading external sstables
we actually don't care about individual indices: on failure we wan't to rebuild them all on
restart, so instead of marking individual indices in need of rebuild, we could instead have
a special entry (such as all_indexes_need_rebuild ) in the BUILT_INDEXES table, indicating
that on restart if a table contains that entry it needs to rebuild all indexes. If we did
this we could probably get rid of the {{pendingBuilds}} counter complexity since we wouldn't
race with manual individual index rebuilds on the BUILT_INDEXES table. WDYT?


was (Author: pauloricardomg):
bq. There's still a slight chance that an index is created between an SSTableBeforeAddedNotification
and SSTableAddedNotification and we won't have marked it as building, so we should probably
save the indexes we have marked as building when receiving the SSTableBeforeAddedNotification
and mark any new index as building after receiving an SSTableBeforeAddedNotification but before
building all indexes, and maybe extend the previous unit test to test this unlikely scenario.

The solution above looks a bit ugly, so this made me think that when loading external sstables
we actually don't care about individual indices: on failure we wan't to rebuild them all on
restart, so instead of marking individual indices in need of rebuild, we could instead have
a special entry (such as all_indexes_need_rebuild ) in the BUILT_INDEXES table, indicating
that on restart if a table contains that entry it needs to rebuild all indexes. If we did
this we could probably get rid of the {{pendingBuilds}} counter complexity since we wouldn't
race with manual individual index rebuilds on the BUILT_INDEXES table. WDYT?

> Node failure during 2i update after streaming can have incomplete 2i when restarted
> -----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-10130
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Coordination
>            Reporter: Yuki Morishita
>            Assignee: Andrés de la Peña
>            Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 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 the 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


Mime
View raw message