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

Caleb Rackliffe updated CASSANDRA-21520:
----------------------------------------
    Description: 
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.

  was:
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?


> 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: Caleb Rackliffe
>            Priority: Normal
>             Fix For: 6.x, 7.x, 5.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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to