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 persist even after > that. > > https://gist.github.com/jeromatron/e238e5795b3e79866b83 > > Also, we changed the tombstone_compaction_interval : 1800 and > tombstone_threshold > : 0.1, but it did not help. > > thanks > > > > On Wed, Jul 27, 2016 at 4:05 PM, DuyHai Doan <doanduy...@gmail.com> wrote: > >> This feature is also exposed directly in nodetool from version Cassandra >> 3.4 >> >> nodetool compact --user-defined <SSTable file> >> >> On Wed, Jul 27, 2016 at 9:58 PM, Vinay Chella <vche...@netflix.com> >> 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 >>> >>> current time >= deletion(tombstone time)+ GC_Grace_seconds >>> >>> >>> File level compaction >>> >>> /usr/bin/java -jar cmdline-jmxclient-0.10.3.jar - localhost: >>>> { >>>> port} >>>> org.apache.cassandra.db:type=CompactionManager >>>> forceUserDefinedCompaction="'${KEYSPACE}','${ >>>> SSTABLEFILENAME >>>> }'"" >>>> >>>> >>> >>> >>> >>> On Wed, Jul 27, 2016 at 11:59 AM, sai krishnam raju potturi < >>> pskraj...@gmail.com> wrote: >>> >>>> hi; >>>> we have a columnfamily that has around 1000 rows, with one row is >>>> really huge (million columns). 95% of the row contains tombstones. Since >>>> there exists just one SSTable , there is going to be no compaction kicked >>>> in. Any way we can get rid of the tombstones in that row? >>>> >>>> Userdefined compaction nor nodetool compact had no effect. Any ideas >>>> folks? >>>> >>>> thanks >>>> >>>> >>>> >>> >>> >> >
