Re: Repair scheduling tools

We at Scylla, implemented repair in a similar way to the Cassandra reaper. We do that using an external application, written in go that manages repair for multiple clusters and saves the data in an external Scylla cluster. The logic resembles the reaper one with some specific internal sharding opti

Re: Repair scheduling tools

Simon, You could still do load aware repair outside of the main process by reading Cassandra's metrics. In general, I don't think the maintenance tasks necessarily need to live in the main process. They could negatively impact the read / write path. Unless strictly required by the serving path,

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 exp

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

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: 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 have

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 out some of the issues

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 wrote: >

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 2 >>> months, >>> so say

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 qu

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: 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 great for our users if we mo

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: 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 to bring up the idea o

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 desi

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, specifical

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 it's worth (and based on

Re: Roadmap for 4.0

For what it's worth (and based on the project experience), I think the strategy of "let's agree on a list of tickets everyone would love to get in before we freeze 4.0" doesn't work very well (it's largely useless, expect for making us feel good about not releasing anything). Those lists always end

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 wrote: > It's changed to t