Thank you Kurt
> On Mar 14, 2018, at 5:57 PM, kurt greaves <k...@instaclustr.com> wrote: > > 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 >>>>>>>>> >>>>>>> >>>>> >>>> >>> >
