Thank you very much! Yes I am using reaper! Best,
Sergio On Wed, Jan 22, 2020, 8:00 AM Reid Pinchback <rpinchb...@tripadvisor.com> wrote: > Sergio, if you’re looking for a new frequency for your repairs because of > the change, if you are using reaper, then I’d go for repair_freq <= > gc_grace / 2. > > > > Just serendipity with a conversation I was having at work this morning. > When you actually watch the reaper logs then you can see situations where > unlucky timing with skipped nodes can make the time to remove a tombstone > be up to 2 x repair_run_time. > > > > If you aren’t using reaper, your mileage will vary, particularly if your > repairs are consistent in the ordering across nodes. Reaper can be > moderately non-deterministic hence the need to be sure you can complete at > least two repair runs. > > > > R > > > > *From: *Sergio <lapostadiser...@gmail.com> > *Reply-To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Date: *Tuesday, January 21, 2020 at 7:13 PM > *To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Subject: *Re: Is there any concern about increasing gc_grace_seconds > from 5 days to 8 days? > > > > *Message from External Sender* > > 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 <jji...@gmail.com> wrote: > > 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 tombstones shadow data, so you'll re-stream the tombstone to the other > replicas) > > > > On Tue, Jan 21, 2020 at 3:28 PM Elliott Sims <elli...@backblaze.com> > wrote: > > 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 Tue, Jan 21, 2020 at 2:14 PM Sergio <lapostadiser...@gmail.com> wrote: > > https://stackoverflow.com/a/22030790 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_22030790&d=DwMFaQ&c=9Hv6XPedRSA-5PSECC38X80c1h60_XWA4z1k_R1pROA&r=OIgB3poYhzp3_A7WgD7iBCnsJaYmspOa2okNpf6uqWc&m=qt1NAYTks84VVQ4WGXWkK6pw85m3FcuUjPRJPdIHMdw&s=aEgz5F5HRxPT3w4hpfNXQRhcchwRjrpf7KB3QyywO_Q&e=> > > > > For CQLSH > > alter table <table_name> with GC_GRACE_SECONDS = <seconds>; > > > > > > Il giorno mar 21 gen 2020 alle ore 13:12 Sergio <lapostadiser...@gmail.com> > 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 need to perform just : > > UPDATE COLUMN FAMILY cf with GC_GRACE = 691,200; //8 days > > Is it correct? > > Thanks, > > Sergio > >
