cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8979) MerkleTree mismatch for deleted and non-existing rows
Date Thu, 02 Apr 2015 13:28:53 GMT

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

Stefan Podkowinski commented on CASSANDRA-8979:
-----------------------------------------------

Yes, I guess the implications for clusters running mixed versions haven't been really considered.
I've added a new patch which makes sure the digest calculation for non-empty rows will stay
the same after the patch.

Changes in detail:

PrecompactedRow

Would be reverted to exact same code as before the patch. 
The issue described in the ticket would still be solved by the patched Validator, which now
only creates a new RowHash in case the digest has been updated. The PrecompactRow never updated
the digest in case of empty rows. 


LazilyCompactedRow

I've changed the digest update call condition to: nonEmpty || !DeletionTime.LIVE
this makes sure that digest update is called in any case for non-empty rows (and will thus
be backwards compatible) but still skips update for empty rows with LIVE deletes.

As for backwards compatability it still should be clear that after the patch empty/purged
rows will now not create a digest in the MT anymore compared to versions before the patch.
In this case those rows would still be streamed after repairs. This applies to both Precompacted
and Lazy. One node with the new version would create the same mismatch as a node with the
old version and a missing row.


> MerkleTree mismatch for deleted and non-existing rows
> -----------------------------------------------------
>
>                 Key: CASSANDRA-8979
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8979
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>             Fix For: 2.1.5
>
>         Attachments: 8979-AvoidBufferAllocation-2.0_patch.txt, 8979-LazilyCompactedRow-2.0.txt,
8979-RevertPrecompactedRow-2.0.txt, cassandra-2.0-8979-lazyrow_patch.txt, cassandra-2.0-8979-validator_patch.txt,
cassandra-2.0-8979-validatortest_patch.txt, cassandra-2.1-8979-lazyrow_patch.txt, cassandra-2.1-8979-validator_patch.txt
>
>
> Validation compaction will currently create different hashes for rows that have been
deleted compared to nodes that have not seen the rows at all or have already compacted them
away. 
> In case this sounds familiar to you, see CASSANDRA-4905 which was supposed to prevent
hashing of expired tombstones. This still seems to be in place, but does not address the issue
completely. Or there was a change in 2.0 that rendered the patch ineffective. 
> The problem is that rowHash() in the Validator will return a new hash in any case, whether
the PrecompactedRow did actually update the digest or not. This will lead to the case that
a purged, PrecompactedRow will not change the digest, but we end up with a different tree
compared to not having rowHash called at all (such as in case the row already doesn't exist).
> As an implication, repair jobs will constantly detect mismatches between older sstables
containing purgable rows and nodes that have already compacted these rows. After transfering
the reported ranges, the newly created sstables will immediately get deleted again during
the following compaction. This will happen for each repair run over again until the sstable
with the purgable row finally gets compacted. 



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

Mime
View raw message