Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: <52F39417.7060907@gmail.com>
References: 
 <CAC45OSv3WYVEh6o0DoK1QwidhgyKeEOX8m2egzcR5dEAddEqRQ@mail.gmail.com>
	<52F39417.7060907@gmail.com>
Date: Thu, 6 Feb 2014 10:53:36 -0500
Message-ID: 
 <CAC45OSv3Aig=ztV=TowHDErQVrQjHvNW=wahJB3MWjquaOOVig@mail.gmail.com>
Subject: Re: First SSTable file is not being compacted
From: Sameer Farooqui <sameer@blueplastic.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=001a11351c9a5ae9d904f1bee080

--001a11351c9a5ae9d904f1bee080
Content-Type: text/plain; charset=ISO-8859-1

Yeah, it's definitely repeatable. I have a lab environment set up where the
issue is occurring and I've recreated the lab environment 4 - 5 times and
it's occurred each time.

In my demodb.users CF I currently have 2 data SSTables on disk
(demodb-users-jb-1-Data.db and demodb-users-jb-6-Data.db). However, in
OpsCenter the CF: SSTable Count (demodb.users) graph shows only one SSTable.

The nodetool cfstats command also shows "SSTable count: 1" for this CF.


- SF


On Thu, Feb 6, 2014 at 8:54 AM, Chris Burroughs
<chris.burroughs@gmail.com>wrote:

> On 02/06/2014 01:17 AM, Sameer Farooqui wrote:
>
>> I'm running C* 2.0.4 and when I have a handful of SSTable files and
>> trigger
>> a manual compaction with 'nodetool compact' the first SSTable file doesn't
>> get compacted away.
>>
>> Is there something special about the first SSTable that it remains even
>> after a SizedTierCompaction?
>>
>
>
> No, this is not expected behavior.  Do the number of live SSTables
> reported match what is on disk?  Do you have a procedure that can repeat
> this?
>
>

--001a11351c9a5ae9d904f1bee080
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yeah, it&#39;s definitely repeatable. I have a lab environ=
ment set up where the issue is occurring and I&#39;ve recreated the lab env=
ironment 4 - 5 times and it&#39;s occurred each time.<div><br></div><div>In=
 my demodb.users CF I currently have 2 data SSTables on disk (demodb-users-=
jb-1-Data.db and demodb-users-jb-6-Data.db). However, in OpsCenter the=A0CF=
: SSTable Count (demodb.users) graph shows only one SSTable.</div>
<div><br></div><div>The nodetool cfstats command also shows &quot;SSTable c=
ount: 1&quot; for this CF.</div><div><br></div><div><br></div><div>- SF</di=
v></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Th=
u, Feb 6, 2014 at 8:54 AM, Chris Burroughs <span dir=3D"ltr">&lt;<a href=3D=
"mailto:chris.burroughs@gmail.com" target=3D"_blank">chris.burroughs@gmail.=
com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 0=
2/06/2014 01:17 AM, Sameer Farooqui wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I&#39;m running C* 2.0.4 and when I have a handful of SSTable files and tri=
gger<br>
a manual compaction with &#39;nodetool compact&#39; the first SSTable file =
doesn&#39;t<br>
get compacted away.<br>
<br>
Is there something special about the first SSTable that it remains even<br>
after a SizedTierCompaction?<br>
</blockquote>
<br>
<br></div></div>
No, this is not expected behavior. =A0Do the number of live SSTables report=
ed match what is on disk? =A0Do you have a procedure that can repeat this?<=
br>
<br>
</blockquote></div><br></div>

--001a11351c9a5ae9d904f1bee080--