[
https://issues.apache.org/jira/browse/CASSANDRA-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-11654:
---------------------------------------
Labels: Tools (was: )
Assignee: Yuki Morishita
Reviewer: Chris Lohfink
Fix Version/s: 3.x
3.0.x
Reproduced In: 3.0.5, 3.0.4, 3.6 (was: 3.0.4, 3.0.5, 3.6)
Status: Patch Available (was: Open)
> sstabledump is not able to properly print out SSTable that may contain
> historical (but "shadowed") row tombstone
> ----------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-11654
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11654
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Reporter: Wei Deng
> Assignee: Yuki Morishita
> Labels: Tools
> Fix For: 3.0.x, 3.x
>
>
> It is pretty trivial to reproduce. Here are the steps I used (on a single
> node C* 3.x cluster):
> {noformat}
> echo "CREATE KEYSPACE IF NOT EXISTS testks WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': '1'};" | cqlsh
> echo "CREATE TABLE IF NOT EXISTS testks.testcf ( k int, c text, val0_int int,
> PRIMARY KEY (k, c) );" | cqlsh
> echo "INSERT INTO testks.testcf (k, c, val0_int) VALUES (1, 'c1', 100);" |
> cqlsh
> echo "DELETE FROM testks.testcf where k=1 and c='c1';" | cqlsh
> echo "INSERT INTO testks.testcf (k, c, val0_int) VALUES (1, 'c1', 100);" |
> cqlsh
> nodetool flush testks testcf
> echo "SELECT * FROM testks.testcf;" | cqlsh
> {noformat}
> The last step from above will confirm that there is one live row in the
> testks.testcf table. However, if you now go to the actual SSTable file
> directory and run sstabledump like the following, you will see the row is
> still marked as deleted and no row content is shown:
> {noformat}
> $ sstabledump ma-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 18,
> "clustering" : [ "c1" ],
> "liveness_info" : { "tstamp" : 1461633248542342 },
> "deletion_info" : { "deletion_time" : 1461633248212499, "tstamp" :
> 1461633248 }
> }
> ]
> }
> ]
> {noformat}
> This is reproduced in both latest 3.0.5 and 3.6-snapshot (i.e. trunk as of
> Apr 25, 2016).
> Looks like only row tombstone is affecting sstabledump. If you generate cell
> tombstones, even if you delete all non-PK & non-static columns in the row, as
> long as there is no explicit row delete (so the clustering is still
> considered alive), sstabledump will work just fine, see the following example
> steps:
> {noformat}
> echo "CREATE KEYSPACE IF NOT EXISTS testks WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': '1'};" | cqlsh
> echo "CREATE TABLE IF NOT EXISTS testks.testcf ( k int, c text, val0_int int,
> val1_int int, PRIMARY KEY (k, c) );" | cqlsh
> echo "INSERT INTO testks.testcf (k, c, val0_int, val1_int) VALUES (1, 'c1',
> 100, 200);" | cqlsh
> echo "DELETE val0_int, val1_int FROM testks.testcf where k=1 and c='c1';" |
> cqlsh
> echo "INSERT INTO testks.testcf (k, c, val0_int, val1_int) VALUES (1, 'c1',
> 300, 400);" | cqlsh
> nodetool flush testks testcf
> echo "select * from testks.testcf;" | cqlsh
> $ sstabledump ma-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 18,
> "clustering" : [ "c1" ],
> "liveness_info" : { "tstamp" : 1461634633566479 },
> "cells" : [
> { "name" : "val0_int", "value" : "300" },
> { "name" : "val1_int", "value" : "400" }
> ]
> }
> ]
> }
> ]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
