[
https://issues.apache.org/jira/browse/CASSANDRA-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054219#comment-16054219
]
Andrés de la Peña edited comment on CASSANDRA-10130 at 6/19/17 3:36 PM:
------------------------------------------------------------------------
I have merged the changes by [~pauloricardomg].
bq. I really think it makes the code cleaner and less prone to errors to update
SecondaryIndexManager state (needsFullRebuild, queryableIndexes and
inProgressBuilds) exclusively in the mark* methods rather than in many places
throughout the code.
bq. I know that would be cleaner, but bear in mind that's also a change from
previous behaviour and would cause the index to be considered queryable even if
the initialization task failed and later a non-full rebuild succeeded. I'm not
a fan of that, but I'll leave it to you guys.
What we can do here is adding {{isFullRebuild}} to {{markIndexBuilt}} to only
set the index as queryable if the method is invoked by a full index rebuild, as
it is done
[here|https://github.com/adelapena/cassandra/commit/ca7da30f621e742f85b6a7b1f66d320ba224a6a4].
I have also added a new test to check how a successful partial build doesn't
set the index as queryable when the initialization has failed.
bq. I'd propose to either/both add a cassandra.yaml option to enable automatic
rebuilds explicitly or/and add a flag to NodeTool to rebuild indexes only if
not already built.
Adding a cassandra.yaml option seems like a good idea, I think we could address
it as an improvement in a separate ticket. About adding a flag to {{nodetool
rebuild_index}}, I think I'd prefer to add a command to let the user query
if/which indexes are built in a more friendly way than looking in the
{{IndexInfo}} table. Does it make sense?
was (Author: adelapena):
I have merged the changes by [~pauloricardomg].
bq. I really think it makes the code cleaner and less prone to errors to update
SecondaryIndexManager state (needsFullRebuild, queryableIndexes and
inProgressBuilds) exclusively in the mark* methods rather than in many places
throughout the code.
bq. I know that would be cleaner, but bear in mind that's also a change from
previous behaviour and would cause the index to be considered queryable even if
the initialization task failed and later a non-full rebuild succeeded. I'm not
a fan of that, but I'll leave it to you guys.
What we can do here is adding {{isFullRebuild}} to {{markIndexBuilt}} to only
set the index as queryable, as it is done
[here|https://github.com/adelapena/cassandra/commit/ca7da30f621e742f85b6a7b1f66d320ba224a6a4].
I have also added a new test to check how a successful partial build doesn't
set the index as queryable when the initialization has failed.
bq. I'd propose to either/both add a cassandra.yaml option to enable automatic
rebuilds explicitly or/and add a flag to NodeTool to rebuild indexes only if
not already built.
Adding a cassandra.yaml option seems like a good idea, I think we could address
it as an improvement in a separate ticket. About adding a flag to {{nodetool
rebuild_index}}, I think I'd prefer to add a command to let the user query
if/which indexes are built in a more friendly way than looking in the
{{IndexInfo}} table. Does it make sense?
> 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
