Re: User Defined Compaction Issue

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

Re: User Defined Compaction Issue

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,

Re: User Defined Compaction Issue

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%

Re: User Defined Compaction Issue

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

User Defined Compaction Issue

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