cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8993) EffectiveIndexInterval calculation is incorrect
Date Thu, 19 Mar 2015 21:26:44 GMT


Tyler Hobbs commented on CASSANDRA-8993:

Okay, I think I have an idea of what's happening.  The 2.0-format SSTable is loaded by 2.1
and is eventually downsampled.  This results in the summary being overwritten on disk (with
every 2048th index entry).  However, we overwrite it with the old 2.0 format, which does _not_
include the sampling level.  Whenever the sstable and summary are reloaded (due to a restart,
etc), there's no sampling level to read from the serialized summary, so it's assumed to be
fully sampled (with every 128th index entry).  I'm pretty sure that's what's leading to this

> EffectiveIndexInterval calculation is incorrect
> -----------------------------------------------
>                 Key: CASSANDRA-8993
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Blocker
>             Fix For: 2.1.4
>         Attachments: 8993.txt
> I'm not familiar enough with the calculation itself to understand why this is happening,
but see discussion on CASSANDRA-8851 for the background. I've introduced a test case to look
for this during downsampling, but it seems to pass just fine, so it may be an artefact of
> The problem was, unfortunately, not manifesting directly because it would simply result
in a failed lookup. This was only exposed when early opening used firstKeyBeyond, which does
not use the effective interval, and provided the result to getPosition().
> I propose a simple fix that ensures a bug here cannot break correctness. Perhaps [~thobbs]
can follow up with an investigation as to how it actually went wrong?

This message was sent by Atlassian JIRA

View raw message