[jira] [Updated] (CASSANDRA-21520) Investigate Safety of SAI Index Rebuilds and ZCS

["Caleb Rackliffe (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-21520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Caleb Rackliffe updated CASSANDRA-21520:
----------------------------------------
    Fix Version/s: 6.0.x

> Investigate Safety of SAI Index Rebuilds and ZCS
> ------------------------------------------------
>
>                 Key: CASSANDRA-21520
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-21520
>             Project: Apache Cassandra
>          Issue Type: Bug
>          Components: Consistency/Streaming, Feature/SAI
>            Reporter: Caleb Rackliffe
>            Assignee: Pranav Shenoy
>            Priority: Normal
>             Fix For: 5.0.x, 6.0.x, 7.x
>
>
> When zero-copy streaming and SAI index rebuilds overlap with one another, there are some potentially problematic interactions.
> 1.) What happens when we try to stream an entire SSTable, create a manifest, but then the relevant SAI components are deleted before the stream writer creates a channel for the outgoing file?
> 2.) What happens in the above case, if a rebuild deletes an old component, then begins writing a new one after the streaming manifest has been created?
> 3.) To what extent do existing mechanisms, like the assertions in ComponentContext, fail streaming operations right now rather than propagate corruption?
> 4.) When corrupted index components exist on disk, should streaming operations block index rebuilds? Should index rebuilds block streaming? Should active index builds degrade streaming to avoid ZCS and build indexes on the receiver?
> 5.) Should we verify checksums on SAI index components on the sender, rather than just the receiver as we do now?
> A big question that will come up here is whether entire SSTable streaming and index rebuilds block each other, etc.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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