At least set GCGS == max_hint_window_in_ms that way you don't effectively disable hints for the table while your compaction is running. Might be preferable to use nodetool garbagecollect if you don't have enough disk space for a major compaction. Also worth noting you should do a splitting major compaction so you don't end up with one big SSTable when using STCS (also applicable for LCS)
On 14 March 2018 at 18:53, Jeff Jirsa <jji...@gmail.com> wrote: > Can’t advise that without knowing the risk to your app if there’s data > resurrected > > > If there’s no risk, then sure - set gcgs to 0 and force / major compact if > you have the room > > > > -- > Jeff Jirsa > > > On Mar 14, 2018, at 11:47 AM, Madhu-Nosql <odba.ma...@gmail.com> wrote: > > Jeff, > > Thank you i got this- how about Dropping the existing Tombstones right now > can setting gc_grace time to zero per Table level would be good or what > would you suggest? > > On Wed, Mar 14, 2018 at 1:41 PM, Jeff Jirsa <jji...@gmail.com> wrote: > >> What version of Cassandra? >> >> https://issues.apache.org/jira/browse/CASSANDRA-7304 sort of addresses >> this in 2.2+ >> >> >> >> >> On Wed, Mar 14, 2018 at 11:32 AM, Madhu-Nosql <odba.ma...@gmail.com> >> wrote: >> >>> Rahul, >>> >>> Tomstone caused is on the Application driver side so even though they >>> are not using some of the Columns in their logic >>> waht they did is that they mentioned in driver logic that means if you >>> are updateting one Column so the rest of the Columns so the driver >>> automatically >>> pick some nulls, internally behind the schnes cassandra threat them as a >>> Tombstones >>> >>> On Wed, Mar 14, 2018 at 12:58 PM, Rahul Singh < >>> rahul.xavier.si...@gmail.com> wrote: >>> >>>> Then don’t write nulls. That’s the root of the issue. Sometimes they >>>> surface from prepared statements. Othertimes they come because of default >>>> null values in objects. >>>> >>>> -- >>>> Rahul Singh >>>> rahul.si...@anant.us >>>> >>>> Anant Corporation >>>> >>>> On Mar 13, 2018, 2:18 PM -0400, Madhu-Nosql <odba.ma...@gmail.com>, >>>> wrote: >>>> >>>> We assume that's becoz of nulls >>>> >>>> On Tue, Mar 13, 2018 at 12:58 PM, Rahul Singh < >>>> rahul.xavier.si...@gmail.com> wrote: >>>> >>>>> Are you writing nulls or does the data cycle that way? >>>>> >>>>> -- >>>>> Rahul Singh >>>>> rahul.si...@anant.us >>>>> >>>>> Anant Corporation >>>>> >>>>> On Mar 13, 2018, 11:48 AM -0400, Madhu-Nosql <odba.ma...@gmail.com>, >>>>> wrote: >>>>> >>>>> Rahul, >>>>> >>>>> Nodetool scrub is good for rescue, what if its happening all the time? >>>>> >>>>> On Tue, Mar 13, 2018 at 10:37 AM, Rahul Singh < >>>>> rahul.xavier.si...@gmail.com> wrote: >>>>> >>>>>> Do you anticipate this happening all the time or are you just trying >>>>>> to rescue? >>>>>> >>>>>> Nodetool scrub can be useful too. >>>>>> >>>>>> >>>>>> -- >>>>>> Rahul Singh >>>>>> rahul.si...@anant.us >>>>>> >>>>>> Anant Corporation >>>>>> >>>>>> On Mar 13, 2018, 11:29 AM -0400, Madhu-Nosql <odba.ma...@gmail.com>, >>>>>> wrote: >>>>>> >>>>>> I got few ways to Drop Tombstones- Chos Monkey/Zombie Data mainly to >>>>>> avoid Data Resurrection (you deleted data it will comes back in >>>>>> future) >>>>>> >>>>>> I am thinking of below options, let me know if you have any best >>>>>> practice for this >>>>>> >>>>>> 1.using nodetool garbagecollect >>>>>> 2.only_purge_repaired_tombstones >>>>>> 3.At Table level making GC_Grace_period to zero and compact >>>>>> >>>>>> Thanks, >>>>>> Madhu >>>>>> >>>>>> >>>>> >>>> >>> >> >
