You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Andres de la Peña (Jira)" <ji...@apache.org> on 2020/05/04 16:59:00 UTC

[jira] [Commented] (CASSANDRA-13606) Improve handling of 2i initialization failures

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

Andres de la Peña commented on CASSANDRA-13606:
-----------------------------------------------

If I'm understanding the patch, if we create a regular index on a table any write to that base table (including compaction) will fail until the index is completely build. I'm not sure we want this very restrictive behaviour, especially when the index build hasn't even failed. I guess we should have a different behaviour for unfinished and failed index builds, WDYT?

I'm not sure about what making the index not available for writes should mean. The patch is making to fail even compactions of the base table, which might be excessive. Perhaps we should just ignore writes to a problematic index, without making the base table operation to fail?

 

> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org