Re: Cassandra2.0.14 : Obsolete files not being deleted after compaction

On Tue, Jan 21, 2020 at 8:58 PM manish khandelwal < manishkhandelwa...@gmail.com> wrote: > Thanks Nitan, > > Thanks for your reply. > > I am using following methodology to find obsolete sstables and just want > to make sure that I don't delete live data if I delete them . > > In the following log

Re: Cassandra2.0.14 : Obsolete files not being deleted after compaction

Thanks Nitan, Thanks for your reply. I am using following methodology to find obsolete sstables and just want to make sure that I don't delete live data if I delete them . In the following logs I searched for sstable " keyspace-columnfamily-jb-456789" and found that this "*CompactionExecutor:19

Re: Is there any concern about increasing gc_grace_seconds from 5 days to 8 days?

Thank you very much for your response. The considerations mentioned are the ones that I was expecting. I believe that I am good to go. I just wanted to make sure that there was no need to run any other extra command beside that one. Best, Sergio On Tue, Jan 21, 2020, 3:55 PM Jeff Jirsa wrote:

Re: Is there any concern about increasing gc_grace_seconds from 5 days to 8 days?

Note that if you're actually running repairs within 5 days, and you adjust this to 8, you may stream a bunch of tombstones across in that 5-8 day window, which can increase disk usage / compaction (because as you pass 5 days, one replica may gc away the tombstones, the others may not because the to

Re: Is there any concern about increasing gc_grace_seconds from 5 days to 8 days?

In addition to extra space, queries can potentially be more expensive because more dead rows and tombstones will need to be scanned. How much of a difference this makes will depend drastically on the schema and access pattern, but I wouldn't expect going from 5 days to 8 to be very noticeable. On

Testing Cassandra 4.0 Pre-releases on Windows

Hi Cassandra Users, The Cassandra dev community is looking for users of Cassandra running on windows to test compatibility of the 4.0 alpha / beta / rc releases. If you run on windows and have time / resources to test, please report any compatibility issues you find to the dev mailing list or JIR

Re: Is there any concern about increasing gc_grace_seconds from 5 days to 8 days?

https://stackoverflow.com/a/22030790 For CQLSH alter table with GC_GRACE_SECONDS = ; Il giorno mar 21 gen 2020 alle ore 13:12 Sergio ha scritto: > Hi guys! > > I just wanted to confirm with you before doing such an operation. I expect > to increase the space but nothing more than this. I

Is there any concern about increasing gc_grace_seconds from 5 days to 8 days?

Hi guys! I just wanted to confirm with you before doing such an operation. I expect to increase the space but nothing more than this. I need to perform just : UPDATE COLUMN FAMILY cf with GC_GRACE = 691,200; //8 days Is it correct? Thanks, Sergio

Re: Cassandra2.0.14 : Obsolete files not being deleted after compaction

If you are certain that you don’t need data, your plan is good. Make sure to delete all the files for any given sequence number ie data, index, toc etc Regards, Nitan Cell: 510 449 9629 > On Jan 21, 2020, at 5:36 AM, manish khandelwal > wrote: > >  > Hi Team > > I am observing some obsolete

Call for presentations for ApacheCon North America 2020 now open

Dear Apache enthusiast, (You’re receiving this message because you are subscribed to one or more project mailing lists at the Apache Software Foundation.) The call for presentations for ApacheCon North America 2020 is now open at https://apachecon.com/acna2020/cfp ApacheCon will be held at

Cassandra2.0.14 : Obsolete files not being deleted after compaction

Hi Team I am observing some obsolete files in Cassandra 2.0.14 which are already compacted but not removed from the system after compaction. As per CASSANDRA-7872 , after GC grace period has passed the sstables are open for read again and can