[
https://issues.apache.org/jira/browse/CASSANDRA-13606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099809#comment-17099809
]
Andres de la Peña commented on CASSANDRA-13606:
-----------------------------------------------
The index initialization failure is already logged, so I'm not sure whether it
would be useful to log every write to the base table that can't go into the
not-writable index. Perhaps we could the {{SIM.writableIndexes}} set instead of
{{SIM#indexes}} when we decide which indexes are going to be affected be a
write transaction, so we would just silently exclude not-writable indexes from
every write until we they have recovered.
As for providing a method to recover distinct from index rebuilds, and not
missing initialization work, I see two problems:
* The new {{Index#getRecoveryTaskSupport}} method is only called from
{{SIM#recoverIndexesBlocking}}, and I think the later is never called.
* Doing a full index rebuild with {{nodetool rebuild_index}} invokes
{{SIM#rebuildIndexesBlocking}}, that makes the index available for both reads
and writes without calling neither {{Index#getInitializationTask}} nor
{{Index#getRecoveryTaskSupport}}.
I can think of two different ways of differentiating the rebuild of a properly
initialized index from recovering from an initialization failure:
- Having a separate nodetool command, for example {{nodetool recover_index}},
that calls {{SIM#recoverIndexesBlocking}}, that calls the new
{{Index#getRecoveryTaskSupport}}.
- Keep the current {{nodetool rebuild_index}} command for both rebuild and
recovery, but use {{Index#getRecoveryTaskSupport}} under the hood if we know
that the index has failed during its initialization.
WDYT?
> Improve handling of 2i initialization failures
> ----------------------------------------------
>
> Key: CASSANDRA-13606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13606
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
> Reporter: Sergio Bossa
> Assignee: Berenguer Blasi
> Priority: Normal
> Fix For: 4.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CASSANDRA-10130 fixes the 2i build management, but initialization failures
> are still not properly handled, most notably because:
> * Initialization failures make the index non-queryable, but it can still be
> written to.
> * Initialization failures can be recovered via full rebuilds.
> Both points above are probably suboptimal because the initialization logic
> could be more complex than just an index build, hence it shouldn't be made
> recoverable via a simple rebuild, and could cause the index to be fully
> unavailable not just for reads, but for writes as well.
> So, we should better handle initialization failures by:
> * Allowing the index implementation to specify if unavailable for reads,
> writes, or both.
> * Providing a proper method to recover, distinct from index rebuilds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
