Alain RODRIGUEZ >>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I just released a detailed post about tombstones today that might
>>>>>>>> be of some interes
>>>>>>> http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html
>>>>>>>
>>>>>>> 220kb worth of tombstones doesn’t seem like enough to worry about.
>>>>>>>
>>>>>>>
>>>>>>> +
e rather than tuning other options so aggressively. The "single
>>>>>> SSTable compaction" section of my post might help you on this issue:
>>>>>> http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html#single-sstable-compaction
>>
r options so aggressively. The "single
>>>>>> SSTable compaction" section of my post might help you on this issue:
>>>>>> http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html#single-sstable
could
>>>>> be more efficient evicting tombstones.
>>>>>
>>>>> we have a columnfamily that has around 1000 rows, with one row is
>>>>>> really huge (million columns)
>>>>>
>>>>>
>>>>> I am sorry
de rows are something you want to avoid while using 2.0.14
>>>> (which is no longer supported for about a year now). I know it is not
>>>> always easy and never the good time, but maybe should you consider
>>>> upgrading both your model and your version of C
del and your version of Cassandra (regardless of the
>>> fact you manage to solve this issue or not with
>>> "unchecked_tombstone_compaction").
>>>
>>> Good luck,
>>>
>>> C*heers,
>>> -------
>>> Alain Rodr
pickle.com
>> France
>>
>> The Last Pickle - Apache Cassandra Consulting
>> http://www.thelastpickle.com
>>
>> 2016-07-28 0:00 GMT+02:00 sai krishnam raju potturi
>> :
>>
>>> The read queries are continuously failing though becaus
ntinuously failing though because of the
>> tombstones. "Request did not complete within rpc_timeout."
>>
>> thanks
>>
>>
>> On Wed, Jul 27, 2016 at 5:51 PM, Jeff Jirsa
>> wrote:
>>
>>> 220kb worth of tombstones doesn’t seem like eno
irsa
>> wrote:
>>
>>> 220kb worth of tombstones doesn’t seem like enough to worry about.
>>>
>>>
>>>
>>>
>>>
>>> *From: *sai krishnam raju potturi
>>> *Reply-To: *"user@cassandra.apache.org"
&g
tones doesn’t seem like enough to worry about.
>>
>>
>>
>>
>>
>> *From: *sai krishnam raju potturi
>> *Reply-To: *"user@cassandra.apache.org"
>> *Date: *Wednesday, July 27, 2016 at 2:43 PM
>> *To: *Cassandra Users
>> *Subject: *Re: Re
> *From: *sai krishnam raju potturi
> *Reply-To: *"user@cassandra.apache.org"
> *Date: *Wednesday, July 27, 2016 at 2:43 PM
> *To: *Cassandra Users
> *Subject: *Re: Re : Purging tombstones from a particular row in SSTable
>
>
>
> and also the sstable size in questi
220kb worth of tombstones doesn’t seem like enough to worry about.
From: sai krishnam raju potturi
Reply-To: "user@cassandra.apache.org"
Date: Wednesday, July 27, 2016 at 2:43 PM
To: Cassandra Users
Subject: Re: Re : Purging tombstones from a particular row in SSTable
an
and also the sstable size in question is like 220 kb in size.
thanks
On Wed, Jul 27, 2016 at 5:41 PM, sai krishnam raju potturi <
pskraj...@gmail.com> wrote:
> it's set to 1800 Vinay.
>
> bloom_filter_fp_chance=0.01 AND
> caching='KEYS_ONLY' AND
> comment='' AND
> dclocal_read_repair
it's set to 1800 Vinay.
bloom_filter_fp_chance=0.01 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.10 AND
gc_grace_seconds=1800 AND
index_interval=128 AND
read_repair_chance=0.00 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='fal
What is your GC_grace_seconds set to?
On Wed, Jul 27, 2016 at 1:13 PM, sai krishnam raju potturi <
pskraj...@gmail.com> wrote:
> thanks Vinay and DuyHai.
>
> we are using verison 2.0.14. I did "user defined compaction" following
> the instructions in the below link, The tombstones still persi
thanks Vinay and DuyHai.
we are using verison 2.0.14. I did "user defined compaction" following
the instructions in the below link, The tombstones still persist even after
that.
https://gist.github.com/jeromatron/e238e5795b3e79866b83
Also, we changed the tombstone_compaction_interval : 1800
This feature is also exposed directly in nodetool from version Cassandra 3.4
nodetool compact --user-defined
On Wed, Jul 27, 2016 at 9:58 PM, Vinay Chella wrote:
> You can run file level compaction using JMX to get rid of tombstones in
> one SSTable. Ensure you set GC_Grace_seconds such that
>
You can run file level compaction using JMX to get rid of tombstones in one
SSTable. Ensure you set GC_Grace_seconds such that
current time >= deletion(tombstone time)+ GC_Grace_seconds
File level compaction
/usr/bin/java -jar cmdline-jmxclient-0.10.3.jar - localhost:
> {
> port}
> org.apac
19 matches
Mail list logo
