Re: CommitLogSegmentManager verbose debug log

Hi Jay, Well the log in itself does not provide useful information (like segment number or sthg like that), so IMHO trace would be a better level for this one I agree that one log per sec may not be seen that verbose ! Thank you On 30 March 2018 at 06:36, Jay Zhuang

Re: Repair scheduling tools

LastPickle's reaper should be the starting point of any discussion on repair scheduling. On Tue, Apr 3, 2018 at 12:48 PM, Blake Eggleston wrote: > Hi dev@, > > > > The question of the best way to schedule repairs came up on > CASSANDRA-14346, and I thought it would be good

Re: Roadmap for 4.0

+1 Even though I suggested clearing blockers, I'm equally happy with a time-boxed event to draw the line in the sand. As long as its something clear to work towards with appropriate commitment from folk. On Tue, Apr 3, 2018 at 8:10 AM Sylvain Lebresne wrote: > For what

Re: Roadmap for 4.0

I’d prefer to time box it as well. I like Sylvain’s suggestion, although I’d also be comfortable with setting a more aggressive cutoff date for features (maybe a month), given all the stuff that’s already in. If we plan on a follow up (4.1/5.0) in 6 months I *hope* there will be less of a

Repair scheduling tools

Hi dev@, The question of the best way to schedule repairs came up on CASSANDRA-14346, and I thought it would be good to bring up the idea of an external tool on the dev list. Cassandra lacks any sort of tools for automating routine tasks that are required for running clusters,

Re: Repair scheduling tools

This document does a really good job of listing out some of the issues of coordinating scheduling repair. Regardless of which camp you fall into, it is certainly worth a read. On Wed, Apr 4, 2018 at 8:10 AM, Joseph Lynch wrote: > I just want to say I think it would be

Re: Roadmap for 4.0

> My concrete proposal would be to declare a feature freeze for 4.0 in 2 > months, > so say June 1th. That leave some time for finishing features that are in > progress, but not too much to get derailed. And let's be strict on that > freeze. I quite like this suggestion. Thanks, Sylvain. > After

Re: Roadmap for 4.0

A hard date for a feature freeze makes sense, a hard date for a release does not. -- Jeff Jirsa > On Apr 3, 2018, at 2:29 PM, Michael Shuler wrote: > > On 04/03/2018 03:51 PM, Nate McCall wrote: >>> My concrete proposal would be to declare a feature freeze for 4.0 in

Re: Repair scheduling tools

I just want to say I think it would be great for our users if we moved repair scheduling into Cassandra itself. The team here at Netflix has opened the ticket and have written a detailed design document

Re: Roadmap for 4.0

On 04/03/2018 03:51 PM, Nate McCall wrote: >> My concrete proposal would be to declare a feature freeze for 4.0 in 2 >> months, >> so say June 1th. That leave some time for finishing features that are in >> progress, but not too much to get derailed. And let's be strict on that >> freeze. > > I

Re: Repair scheduling tools

In seeing so many companies grapple with running repairs successfully in production, and seeing the success of distributed scheduled repair here at Netflix, I strongly believe that adding this to Cassandra would be a great addition to the database. I am hoping, we as a community will make it easy

Re: Roadmap for 4.0

> > A hard date for a feature freeze makes sense, a hard date for a release > does not. Strongly agree. We should also collectively define what "Done" looks like post freeze so we don't end up in bike-shedding hell like we have in the past. On Tue, Apr 3, 2018 at 5:35 PM, Jeff Jirsa

Re: Repair scheduling tools

Agree on including in the distribution but I think repair can live independently and be run / configured separately. -- Rahul Singh rahul.si...@anant.us Anant Corporation On Apr 3, 2018, 4:37 PM -0400, Nate McCall , wrote: > This document does a really good job of listing

RE: Repair scheduling tools

Why not make it configurable? auto_manage_repair_consistancy: true (default: false) Then users can use the built in auto repair function that would be created or continue to handle it as now. Default behavior would be "false" so nothing changes on its own. Just wondering why not

Re: Repair scheduling tools

Repair is critical for running C* and I agree with Roopa that it needs to be part of the offering. I think we should make it easy for new users to run C*. Can we have a side car process which we can add to Apache Cassandra offering and we can put this repair their? I am also fine putting it in C*

Re: Repair scheduling tools

Repair has been a problem for us at Uber. In general I'm in favor of including the scheduling logic in Cassandra daemon. It has the benefit of introducing something like load-aware repair, eg, only schedule repair while no ongoing compaction or traffic is low, etc. As proposed by others, we can