[jira] [Commented] (CASSANDRA-11477) MerkleTree mismatch when a cell is shadowed by a range tombstone in different SSTables

["Fabien Rousseau (JIRA)" <ji...@apache.org>]

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

Fabien Rousseau commented on CASSANDRA-11477:
---------------------------------------------

Hum, in fact, the patch is not worth reviewing it because it does not work.
(When I did it, I forgot that the code was executed for regular compaction as well)

In fact, this ticket is tightly coupled with CASSANDRA-11349. In that ticket, there is a patch that attempts to solve this ticket but also CASSANDRA-11349 and it would be good to have feedback.


> MerkleTree mismatch when a cell is shadowed by a range tombstone in different SSTables
> --------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-11477
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11477
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Fabien Rousseau
>            Assignee: Fabien Rousseau
>              Labels: repair
>         Attachments: 11477-2.1.patch
>
>
> Below is a script which allows to reproduce the problem:
> {noformat}
> ccm create test -v 2.1.13 -n 2 -s
> ccm node1 cqlsh
> CREATE KEYSPACE test_rt WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 2};
> USE test_rt;
> CREATE TABLE IF NOT EXISTS table1 (
>     c1 text,
>     c2 text,
>     c3 text,
>     PRIMARY KEY ((c1), c2)
> );
> INSERT INTO table1 (c1, c2, c3) VALUES ( 'a', 'b', 'c');
> ctrl ^d
> # now flush only one of the two nodes
> ccm node1 flush 
> ccm node1 cqlsh
> USE test_rt;
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> ccm node1 repair test_rt table1
> # now grep the log and observe that there was some inconstencies detected between nodes (while it shouldn't have detected any)
> ccm node1 showlog | grep "out of sync"
> {noformat}
> The wrong hash will be computed on node1, which will include the previously deleted cell, thus resulting in a MT mismatch.
> This is due to the fact that, in LazilyCompactedRow, the RT is not added into the RT tracker (in fact, it's added only if it is GCable, but should always be added).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)