Hi Aaron,
> * Tombstones will only be purged if all fragments of a row are in the
SStable(s) being compacted.
According to my knowledge it's not necessarily true. In a specific case
this patch comes into play:
https://issues.apache.org/jira/browse/CASSANDRA-4671
"We could however purge tombstone if we know that the non-compacted
sstables doesn't have any info that is older than the tombstones we're
about to purge (since then we know that the tombstones we'll consider
can't delete data in non compacted sstables)."
M.
W dniu 12.07.2013 10:25, aaron morton pisze:
That sounds sane to me. Couple of caveats:
* Remember that Expiring Columns turn into Tombstones and can only be purged
after TTL and gc_grace.
* Tombstones will only be purged if all fragments of a row are in the
SStable(s) being compacted.
Cheers
-----------------
Aaron Morton
Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 11/07/2013, at 10:17 PM, Theo Hultberg <t...@iconara.net> wrote:
a colleague of mine came up with an alternative solution that also seems to
work, and I'd just like your opinion on if it's sound.
we run find to list all old sstables, and then use cmdline-jmxclient to run the
forceUserDefinedCompaction function on each of them, this is roughly what we do
(but with find and xargs to orchestrate it)
java -jar cmdline-jmxclient-0.10.3.jar - localhost:7199
org.apache.cassandra.db:type=CompactionManager
forceUserDefinedCompaction=the_keyspace,db_file_name
the downside is that c* needs to read the file and do disk io, but the upside
is that it doesn't require a restart. c* does a little more work, but we can
schedule that during off-peak hours. another upside is that it feels like we're
pretty safe from screwups, we won't accidentally remove an sstable with live
data, the worst case is that we ask c* to compact an sstable with live data and
end up with an identical sstable.
if anyone else wants to do the same thing, this is the full cron command:
0 4 * * * find /path/to/cassandra/data/the_keyspace_name -maxdepth 1 -type f -name
'*-Data.db' -mtime +8 -printf
"forceUserDefinedCompaction=the_keyspace_name,\%P\n" | xargs -t
--no-run-if-empty java -jar /usr/local/share/java/cmdline-jmxclient-0.10.3.jar -
localhost:7199 org.apache.cassandra.db:type=CompactionManager
just change the keyspace name and the path to the data directory.
T#
On Thu, Jul 11, 2013 at 7:09 AM, Theo Hultberg <t...@iconara.net> wrote:
thanks a lot. I can confirm that it solved our problem too.
looks like the C* 2.0 feature is perfect for us.
T#
On Wed, Jul 10, 2013 at 7:28 PM, Marcus Eriksson <krum...@gmail.com> wrote:
yep that works, you need to remove all components of the sstable though, not
just -Data.db
and, in 2.0 there is this:
https://issues.apache.org/jira/browse/CASSANDRA-5228
/Marcus
On Wed, Jul 10, 2013 at 2:09 PM, Theo Hultberg <t...@iconara.net> wrote:
Hi,
I think I remember reading that if you have sstables that you know contain only
data that whose ttl has expired, it's safe to remove them manually by stopping
c*, removing the *-Data.db files and then starting up c* again. is this correct?
we have a cluster where everything is written with a ttl, and sometimes c*
needs to compact over a 100 gb of sstables where we know ever has expired, and
we'd rather just manually get rid of those.
T#
