[jira] [Commented] (CASSANDRA-5454) Changing column_index_size_in_kb on different nodes might corrupt files

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis commented on CASSANDRA-5454:
-------------------------------------------

+1
                
> Changing column_index_size_in_kb on different nodes might corrupt files
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-5454
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5454
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.2.0
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0
>
>         Attachments: 5454.txt
>
>
> RangeTombstones requires that we sometimes repeat a few markers in the data file at index boundaries. Meaning that the same row with different column_index_size_in_kb will not have the same data size.
> This is a problem for streaming, because if the column_index_size_in_kb is different in the source and the destination, the resulting row should have a different size on the destination, but streaming rely on the data size not changing in 1.2.
> Now, while having different column_index_size on different nodes is probably not extremely useful in the long run, you may still have temporal discrepancies because there is no real way to change the setting on all node atomically. Besides, it's not to hard to get different setting on different nodes due to human error. And currently, the result is that if a file is stream while the setting is not consistent, then we'll end up corrupting the received file (due to the fix from CASSANDRA-5418 to be precise).
> I don't see a good way to fix this in 1.2, so users will have to be careful not to have streaming happening while they change the column_index_size_in_kb setting. But in 2.0, once CASSANDRA-4180 is committed, we won't have the problem of having to respect the dataSize from the source on the destination anymore. So basically we should revert the fix from CASSANDRA-5418 (though we may still want to avoid repeating unneeded marker, but the tombstoneTracker can give us that easily).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira