[
https://issues.apache.org/jira/browse/CASSANDRA-14532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kurt Greaves updated CASSANDRA-14532:
-------------------------------------
Description:
So as [~jay.zhuang] mentioned on the mailing list
[here|http://mail-archives.us.apache.org/mod_mbox/cassandra-dev/201806.mbox/<CAAXszS0%3DmCu5ptDccki_coxRwwF0ZFrTYs_EJLpMTDjNT3tFSA%40mail.gmail.com>],
it appears that partition deletions that have passed GCGS are not
propagated/merged properly on read, and also not repaired via read repair.
Steps to reproduce:
{code}
create keyspace test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 3};
create table test.test (id int PRIMARY KEY , data text) WITH gc_grace_seconds =
10;
CONSISTENCY ALL;
INSERT INTO test.test (id, data) values (1, 'test');
ccm node2 stop
CONSISTENCY QUORUM;
DELETE from test.test where id = 1; // wait 10 seconds so HH doesn't propagate
tombstone when starting node2
select * from test.test where id = 1 ;
id | data
----+------
(0 rows)
ccm node2 start
CONSISTENCY ALL;
select * from test.test where id = 1 ;
id | data
----+------
1 | test
alter table test.test WITH gc_grace_seconds = 100000; // GC
select * from test.test where id = 1 ;
id | data
----+------
(0 rows)
{code}
We've also found a seemingly related issue in compaction where trying to
compact an SSTable which contains the partition deletion post GCGS, the
partition deletion won't be removed via compaction. Likely the same code is
causing both bugs.
was:
So as [~jay.zhuang] mentioned on the mailing list here, it appears that
partition deletions that have passed GCGS are not propagated/merged properly on
read, and also not repaired via read repair.
Steps to reproduce:
{code}
create keyspace test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 3};
create table test.test (id int PRIMARY KEY , data text) WITH gc_grace_seconds =
10;
CONSISTENCY ALL;
INSERT INTO test.test (id, data) values (1, 'test');
ccm node2 stop
CONSISTENCY QUORUM;
DELETE from test.test where id = 1; // wait 10 seconds so HH doesn't propagate
tombstone when starting node2
select * from test.test where id = 1 ;
id | data
----+------
(0 rows)
ccm node2 start
CONSISTENCY ALL;
select * from test.test where id = 1 ;
id | data
----+------
1 | test
alter table test.test WITH gc_grace_seconds = 100000; // GC
select * from test.test where id = 1 ;
id | data
----+------
(0 rows)
{code}
We've also found a seemingly related issue in compaction where trying to
compact an SSTable which contains the partition deletion post GCGS, the
partition deletion won't be removed via compaction. Likely the same code is
causing both bugs.
> Partition level deletions past GCGS are not propagated/merged on read
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-14532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14532
> Project: Cassandra
> Issue Type: Bug
> Reporter: Kurt Greaves
> Assignee: Kurt Greaves
> Priority: Major
>
> So as [~jay.zhuang] mentioned on the mailing list
> [here|http://mail-archives.us.apache.org/mod_mbox/cassandra-dev/201806.mbox/<CAAXszS0%3DmCu5ptDccki_coxRwwF0ZFrTYs_EJLpMTDjNT3tFSA%40mail.gmail.com>],
> it appears that partition deletions that have passed GCGS are not
> propagated/merged properly on read, and also not repaired via read repair.
> Steps to reproduce:
> {code}
> create keyspace test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> create table test.test (id int PRIMARY KEY , data text) WITH gc_grace_seconds
> = 10;
> CONSISTENCY ALL;
> INSERT INTO test.test (id, data) values (1, 'test');
> ccm node2 stop
> CONSISTENCY QUORUM;
> DELETE from test.test where id = 1; // wait 10 seconds so HH doesn't
> propagate tombstone when starting node2
> select * from test.test where id = 1 ;
> id | data
> ----+------
> (0 rows)
> ccm node2 start
> CONSISTENCY ALL;
> select * from test.test where id = 1 ;
> id | data
> ----+------
> 1 | test
> alter table test.test WITH gc_grace_seconds = 100000; // GC
> select * from test.test where id = 1 ;
> id | data
> ----+------
> (0 rows)
> {code}
> We've also found a seemingly related issue in compaction where trying to
> compact an SSTable which contains the partition deletion post GCGS, the
> partition deletion won't be removed via compaction. Likely the same code is
> causing both bugs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
