Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of ruslan.usifov@gmail.com
 designates 209.85.161.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F67077A.2000803@filez.com>
References: <4F67077A.2000803@filez.com>
Date: Tue, 20 Mar 2012 02:33:00 +0400
Message-ID: 
 <CAHULbCnTDCTAAendmWXo77X-5rjdRhL5fszsgp7cvyhHHmnhRA@mail.gmail.com>
Subject: Re: repair broke TTL based expiration
From: ruslan usifov <ruslan.usifov@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Do you make major compaction??

2012/3/19 Radim Kolar <hsn@filez.com>:
> I suspect that running cluster wide repair interferes with TTL based
> expiration. I am running repair every 7 days and using TTL expiration tim=
e 7
> days too. Data are never deleted.
> Stored data in cassandra are always growing (watching them for 3 months) =
but
> they should not. If i run manual cleanup, some data are deleted but just
> about 5%. Currently there are about 3-5 times more rows then i estimate.
>
> I suspect that running repair on data with TTL can cause:
>
> 1. time check for expired records is ignored and these data are streamed =
to
> other node and they will be alive again
> =A0or
> 2. streaming data are propagated with full TTL. Lets say that i have ttl =
7
> days, data are stored for 5 days and then repaired, they should be sent t=
o
> other node with ttl 2 days not 7.
>
> Can someone do testing on this case? I could not play with production
> cluster too much.