cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-5454) Changing column_index_size_in_kb on different nodes might corrupt files
Date Tue, 05 Nov 2013 01:18:17 GMT

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

Brandon Williams updated CASSANDRA-5454:
----------------------------------------

    Since Version: 1.2.5

> 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: 1.2.7, 2.0 beta 1
>
>         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 was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message