You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Tyler Hobbs (JIRA)" <ji...@apache.org> on 2016/08/11 20:59:20 UTC
[jira] [Commented] (CASSANDRA-11932) Range tombstones generated
instead of regular ones between 2.1 and 3.0 nodes (in 3.0 -> 2.1 direction)
for some tables
[ https://issues.apache.org/jira/browse/CASSANDRA-11932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417925#comment-15417925 ]
Tyler Hobbs commented on CASSANDRA-11932:
-----------------------------------------
I looked into this, and both {{cassandra-3.0}} and {{trunk}} generate single-cell tombstones for row deletions in "dynamic" CFs.
I'm defining the CF like so:
{noformat}
cfdef = CfDef(
keyspace='ks',
name='cf',
column_type='Standard',
comparator_type='AsciiType',
key_validation_class='AsciiType',
default_validation_class='AsciiType',
column_metadata=[])
client.system_add_column_family(cfdef)
{noformat}
And performing a deletion like:
{noformat}
session.execute("DELETE FROM ks.cf WHERE key = 'key' AND column1 = 'b'")
{noformat}
Looking at extra debug logging, it's sending a single-cell tombstone.
I would also try reproducing with mixed static/dynamic CFs, but we won't support those from CQL until CASSANDRA-10857 is complete, so I suspect that's not what you're describing. Anything else I should try to reproduce with?
> Range tombstones generated instead of regular ones between 2.1 and 3.0 nodes (in 3.0 -> 2.1 direction) for some tables
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-11932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11932
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
> Reporter: Aleksey Yeschenko
> Assignee: Tyler Hobbs
> Fix For: 3.0.x, 3.x
>
>
> Mixed and dynamic Thrift CFs deletions of the dynamic component are being translated into range tombstones in 3.0 -> 2.1 direction. On 3.0 side they are whole row deletions, and {{LegacyLayout::fromRow(CFMetaData, Row)}} turns them into range tombstones even for non-composite, dynamic and mixed Thrift CFs. They should be converted into single-cell deletions instead.
> This is not a correctness problem, strictly speaking, and on its own 'only' causes digest mismatches on reads (and thus a lot of extra traffic w/ CL > ONE) and less efficient representation on wire, though breaks some upgrades in combination with CASSANDRA-11930.
> To reproduce, create a mixed CF while both nodes are on 2.1, upgrade one node to 3.0, and with cqlsh connected to 3.0 remove some rows. Then do a {{SELECT *}} query in cqlsh when connected to 2.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)