RE: Tombstoned data seems to remain after compaction

Hi Jeff I’m appreciate for your detailed explanation :) Ø Expired data gets purged on compaction as long as it doesn’t overlap with other live data. The overlap thing can be difficult to reason about, but it’s meant to ensure correctness in the event that you write a value with ttl 180, th

Re: Tombstoned data seems to remain after compaction

Replies inline > On Dec 10, 2017, at 9:59 PM, "tak...@fujitsu.com" wrote: > > Hi Jeff, > > > Ø Are all of your writes TTL’d in this table? > Yes. We set TTL to 180 days at first, and then altered it to just 1 day > because we noticed the First TTL > setting is too long. > Ok this is d

RE: Tombstoned data seems to remain after compaction

Hi Jeff, Ø Are all of your writes TTL’d in this table? Yes. We set TTL to 180 days at first, and then altered it to just 1 day because we noticed the First TTL setting is too long. Ø Which compaction strategy are you using? We use Size Tiered Compaction Strategy. Ø Are you asking these

Re: Tombstoned data seems to remain after compaction

Mutations read during boot won’t go into the memtable unless the mutation is in the commitlog (which usually means fairly recent - they’re a fixed size) Are all of your writes TTL’d in this table? Which compaction strategy are you using? Are you asking these questions because you’re running out o

RE: Tombstoned data seems to remain after compaction

Hi Kurt, Thanks for your reply! “”” The tombstone needs to compact with every SSTable that contains data for the corresponding tombstone. “”” Let me explain my understanding by example: 1. A record inserted with 180 days TTL (Very long). 2. The record is saved to SSTable (A) when th

?????? ?????? rebuild stream issue

Thanks Jeff,we will have a try. -- -- ??: "Jeff Jirsa";; : 2017??12??11??(??) 1:20 ??: "user"; : Re: ?? rebuild stream issue Just restart the rebuild - it??ll stream some duplicate data but it??ll compact away when it

Re: 回复： rebuild stream issue

Just restart the rebuild - it’ll stream some duplicate data but it’ll compact away when it’s done You can also use subrange repair instead of rebuild if you’re short on disk space -- Jeff Jirsa > On Dec 10, 2017, at 9:14 PM, Peng Xiao <2535...@qq.com> wrote: > > Then,how can we restore the

?????? rebuild stream issue

Then,how can we restore the rebuild?we are using C* 3.11.0 Can we just delete the data files and rerun the rebuild?looks there will be some errors. -- -- ??: "Jeff Jirsa";; : 2017??12??11??(??) 1:07 ??: "user"; : Re: rebui

Re: rebuild stream issue

The streams fail, the rebuild times out if you’ve set a timeout. Or you’ll need to restart the nodes if you didn’t set a streaming timeout. -- Jeff Jirsa > On Dec 10, 2017, at 9:05 PM, Peng Xiao <2535...@qq.com> wrote: > > Dear All, > > We are rebuilding a new DC,if one of the source node wa

rebuild stream issue

Dear All, We are rebuilding a new DC,if one of the source node was restarted,what will happed with the rebuild? Thanks, Peng Xiao

Re: Tombstoned data seems to remain after compaction

The tombstone needs to compact with every SSTable that contains data for the corresponding tombstone. For example the tombstone may be in that SSTable but some data the tombstone covers may possibly be in another SSTable. Only once all SSTables that contain relevant data have been compacted with th

Tombstoned data seems to remain after compaction

Hi All, I'm using the SSTable with Size Tired Compaction Strategy with 10 days gc grace period as default. And sstablemetadata command shows Estimated tombstone drop times As follows after minor compaction on 9th Dec, 2018. (excerpt) Estimated tombstone drop times:%n 1510934467: 2475 * 201