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 of space faster than you expect and you’d like to expire data faster? -- Jeff Jirsa > On Dec 10, 2017, at 9:30 PM, "tak...@fujitsu.com" <tak...@fujitsu.com> wrote: > > 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 the server restarts or some > events like that. > 3. After 180 days pass, The Cassandra process read SSTable (A) on its > boot process ( or, read access?) and put tombstone for the record on *Memory*. > 4. The tombstone on *Memory* is saved to SSTable (B) the next time the > server is rebooted. > > The procedure above splits the sstable for both the record per se and > tombstone. > > My understanding is correct? > > > > Regards, > Takashima > > > From: kurt greaves [mailto:k...@instaclustr.com] > Sent: Monday, December 11, 2017 1:46 PM > To: User <user@cassandra.apache.org> > Subject: 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 the SSTable > containing the tombstone can the tombstone be removed. > > On 11 December 2017 at 01:08, tak...@fujitsu.com <tak...@fujitsu.com> wrote: > 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 * 2017.11.18 > 1510965112: 135 > 1510983500: 225 > 1511003962: 105 > 1511021113: 2280 > 1511037818: 30 > 1511055563: 120 > 1511075445: 165 > > > I just think there are records that should be deleted on > 18th Nov, 2018 in the SSTable by the output above. My understanding > is correct? > > If my understanding I correct, could someone tell me why those > expired data remains after compation? > > > > > Regards, > Takashima > > ---------------------------------------------------------------------- > Toshiaki Takashima > Toyama Fujitsu Limited > +810764553131, ext. 7260292355 > > ---------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
