Awesome explanation :-)
Thanks a lot!
On Tue, Sep 26, 2017 at 3:40 PM, Jeff Jirsa wrote:
> Write row A, flush into sstable 1
> Delete row A, flush the tombstone into sstable 2
>
> The tombstone in sstable 2 can’t be removed until row A in sstable 1 gets
> removed. If you just keep recompacting
Write row A, flush into sstable 1
Delete row A, flush the tombstone into sstable 2
The tombstone in sstable 2 can’t be removed until row A in sstable 1 gets
removed. If you just keep recompacting sstable 2 by itself, the row in sstable
A remains on disk.
--
Jeff Jirsa
> On Sep 26, 2017, at
Thanks Jeff!
I'll try that.
I'm not sure I understand how the tombstones are covering data in another
file. Do you have a small example perhaps?
Thanks again!
On Tue, Sep 26, 2017 at 1:38 AM, Jeff Jirsa wrote:
> The problem is likely that your sstables overlap - your 91% droppable
> tombstones
The problem is likely that your sstables overlap - your 91% droppable
tombstones are probably covering data in another file. Until that data is
removed, those tombstones cant be dropped.
This is why a full major compaction often works better for simply
reclaiming disk space (though it takes a lot
Hi Everyone,
I'm running into an issue I can't seem to Solve.
I execute force compaction in order to reclaim back storage.
Everything was working fine for a time, but after a while I found that
tombstones aren't being removed any longer.
For example, I've compacted the following SSTable:
*21G *S