Hi Kurt,
Thank you very much for your reply.
Well, I’ll try it after do it on test environment just in case ☺
Regards,
Takashima
From: kurt greaves [mailto:k...@instaclustr.com]
Sent: Wednesday, December 13, 2017 8:48 AM
To: User
Subject: Re: Tombstoned data seems to remain after
t;
>
>
> Regards,
>
> Takashima
>
>
>
>
>
> *From:* Jeff Jirsa [mailto:jji...@gmail.com]
> *Sent:* Tuesday, December 12, 2017 2:35 AM
> *To:* cassandra
> *Subject:* Re: Tombstoned data seems to remain after compaction
>
>
>
> Hello Takashima,
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Tuesday, December 12, 2017 2:35 AM
To: cassandra
Subject: Re: Tombstoned data seems to remain after compaction
Hello Takashima,
Answers inline.
On Sun, Dec 10, 2017 at 11:41 PM, tak...@fujitsu.com<mailto:tak...@fujitsu.com>
mail
Hello Takashima,
Answers inline.
On Sun, Dec 10, 2017 at 11:41 PM, tak...@fujitsu.com
wrote:
> 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
” mean that the sstable
> contains tombstones for those records that should expire
>
> on the date of the 1st column? And the data might exist in other SSTables?
>
>
>
> (excerpt)
>
>
> Estimated tombstone drop times:%n
> 1510934467: 2475 * 2017.11.18
>
?
Regards,
Takashima
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Monday, December 11, 2017 3:36 PM
To: user@cassandra.apache.org
Subject: Re: Tombstoned data seems to remain after compaction
Replies inline
On Dec 10, 2017, at 9:59 PM, "tak...@fujitsu.com<mailto:tak...@fujitsu.com>&q
135
> 1510983500: 225
> 1511003962: 105
> 1511021113: 2280
> 1511037818:30
> 1511055563: 120
>
>
>
>
>
> Regards,
> Takashima
>
> From: Jeff Jirsa [mailto:jji...@gmail.com]
> Sent: Monday, December 11, 2017
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Monday, December 11, 2017 2:35 PM
To: user@cassandra.apache.org
Subject: 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
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
> Subject: R
.
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
Subject: Re: Tombstoned data seems to remain after compaction
The
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
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
12 matches
Mail list logo
