leave
ephemeral snapshots behind. Since they're only reclaimed on restart, having
a lot of timeouts can end up filling the the disks if the snapshots get
materialized.
Since the auto repair is running from within Cassandra, we might have more
control over this and implement a proper
Hi Jaydeep,
I've taken a look at the proposed design and have a few comments/questions.
As one of the maintainers of Reaper, I'm looking this through the lens of
how Reaper does things.
*The approach taken in the CEP-37 design is "node-centric" vs a "range
centric" approach (which is the one Rea
Hi folks,
I'm familiar with the codebase and can help with the maintenance and
evolution.
I already have some additional profiles that I can push there which were
never merged in the main branch of tlp-cluster.
I love this tool (I know I'm biased) and hope it gets the attention it
deserves.
Le m
Congratulations folks! And thanks for all the hard work throughout the
years on the Java Driver!
Le jeu. 18 avr. 2024 à 08:39, Jean-Armel Luce a écrit :
> Congratulations everyone !!!
>
> Le jeu. 18 avr. 2024 à 07:37, Berenguer Blasi
> a écrit :
>
>> Congrats all!
>> On 17/4/24 23:23, Jeremiah
Hi Maxim,
I'm part of the K8ssandra team and am very happy to hear that you like our
management API design.
Looking at the CEP, I see that your current target design mentions the
k8ssandra-management-api.
What do you have in mind specifically there? Do you plan on rewriting a
brand new implementat
I confirm we're almost done with CASSANDRA-15580 (Repair QA testing).
Nightly runs are scheduled already and I'm tuning some knobs to get them
nicely stable:
https://app.circleci.com/pipelines/github/riptano/cassandra-rtest?branch=trunk
Andres also created an in-jvm dtest for the mixed cluster repa
Hi Josh,
I can shepherd this ticket and get started early next week.
Cheers,
Alex
Le jeu. 8 oct. 2020 à 20:37, Joshua McKenzie a
écrit :
> I spoke with Blake about
> https://issues.apache.org/jira/browse/CASSANDRA-15580 (new testing and
> validation for Repair) - and unfortunately he's not go
16 tokens is a reasonable compromise for clusters of all sizes, without
being too aggressive. Those with enough C* experience can still lower that
number for their clusters.
Cheers,
-----
Alexander Dejanovski
France
@alexanderdeja
Consultant
Apache Cassandra Consulting
http://www.t
rule for computing the new gen size doesn't make any
sense IMO (at least in the context of Cassandra).
This is one of the most common optimizations we make on clusters, and most
peeps that run Cassandra aren't GC experts (and shouldn't be).
-----
Alexander De
;>>>>>>>>>> This is not the case during host replacement correct?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, Oct 16, 2018 at 10:04 AM Jeremiah D Jordan <
> >>>>>>>>>>>>>>> jeremiah.jor...@gmail.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> As long as we are correctly storing such things in the
> >> system
> >>>>>>>>>>> tables
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> reading them out of the system tables when we do not have
> >> the
> >>>>>>>>>>>>> information
> >>>>>>>>>>>>>>>> from gossip yet, it should not be a problem. (As far as I
> >> know
> >>>>>>>>>> GPFS
> >>>>>>>>>>>>> does
> >>>>>>>>>>>>>>>> this, but I have not done extensive code diving or testing
> >> to
> >>>>>>>>>> make
> >>>>>>>>>>>>> sure all
> >>>>>>>>>>>>>>>> edge cases are covered there)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -Jeremiah
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Oct 16, 2018, at 11:56 AM, sankalp kohli <
> >>>>>>>>>>> kohlisank...@gmail.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Will GossipingPropertyFileSnitch not be vulnerable to
> >> Gossip
> >>>>>>>>>> bugs
> >>>>>>>>>>>>> where
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>> lose hostId or some other fields when we restart C* for
> >> large
> >>>>>>>>>>>>>>>>> clusters(~1000 instances)?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Tue, Oct 16, 2018 at 7:59 AM Jeff Jirsa <
> >> jji...@gmail.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We should, but the 4.0 features that log/reject verbs to
> >>>>>>>>>> invalid
> >>>>>>>>>>>>>>>> replicas
> >>>>>>>>>>>>>>>>>> solves a lot of the concerns here
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> Jeff Jirsa
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Oct 16, 2018, at 4:10 PM, Jeremy Hanna <
> >>>>>>>>>>>>> jeremy.hanna1...@gmail.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We have had PropertyFileSnitch for a long time even
> >> though
> >>>>>>>>>>>>>>>>>> GossipingPropertyFileSnitch is effectively a superset of
> >> what
> >>>>>>>>>> it
> >>>>>>>>>>>>> offers
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> is much less error prone. There are some unexpected
> >> behaviors
> >>>>>>>>>>> when
> >>>>>>>>>>>>>>>> things
> >>>>>>>>>>>>>>>>>> aren’t configured correctly with PFS. For example, if
> you
> >>>>>>>>>>> replace
> >>>>>>>>>>>>>>>> nodes in
> >>>>>>>>>>>>>>>>>> one DC and add those nodes to that DCs property files
> and
> >> not
> >>>>>>>>>> the
> >>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>> DCs
> >>>>>>>>>>>>>>>>>> property files - the resulting problems aren’t very
> >>>>>>>>>>> straightforward
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> troubleshoot.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We could try to improve the resilience and fail fast
> >> error
> >>>>>>>>>>>> checking
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> error reporting of PFS, but honestly, why wouldn’t we
> >> deprecate
> >>>>>>>>>>> and
> >>>>>>>>>>>>>>>> remove
> >>>>>>>>>>>>>>>>>> PropertyFileSnitch? Are there reasons why GPFS wouldn’t
> >> be
> >>>>>>>>>>>>> sufficient
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> replace it?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>
> -
> >>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> dev-unsubscr...@cassandra.apache.org
> >>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>> dev-h...@cassandra.apache.org
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >> -
> >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> dev-unsubscr...@cassandra.apache.org
> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> dev-h...@cassandra.apache.org
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>
> >> -
> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> dev-unsubscr...@cassandra.apache.org
> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> dev-h...@cassandra.apache.org
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >> -
> >>>>>>>>>>>>>> To unsubscribe, e-mail:
> dev-unsubscr...@cassandra.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> >> dev-h...@cassandra.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>
> -
> >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail:
> dev-h...@cassandra.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> -
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> -
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>
> >>
>
> --
-
Alexander Dejanovski
France
@alexanderdeja
Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com
e right now we are in the
> process of eliminating the distinction we used to make which is that DEBUG
> is safe to turn on in production and TRACE is not.
>
> Ariel
>
> On Tue, Mar 20, 2018, at 12:36 PM, Alexander Dejanovski wrote:
> > Ariel,
> >
> > the current plan
qos.ch/manual/layouts.html#marker>
> > >>> https://www.slf4j.org/faq.html#fatal <
> https://www.slf4j.org/faq.html#fatal>
> > >>>
> > >>>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --
-
Alexander Dejanovski
France
@alexanderdeja
Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com
log statement that runs once or more per read or write should be
> easy
> >>>> to
> >>>>> spot. I haven’t measured the impact though. And as a bonus by having
> this
> >>>>> we can spot a variety of performance issues introduced by all kinds
&g
> was asynchronous would give people a “production” debug log.
> https://issues.apache.org/jira/browse/CASSANDRA-10241
> >> If there are some things going out at DEBUG that cause performance
> issues then most likely those should be moved to TRACE so that debug
> logging can s
't come for free and that it lowers read performance in 2.2.
Was there any specific reason why it was enabled by default in 2.2 ?
Is anyone opposed to disabling debug logging by default in all branches ?
--
-
Alexander Dejanovski
France
@alexanderdeja
Consultant
Ap
have to think about. I would prefer to avoid any more
> configuration settings as complex as back_pressure_strategy going forward.
>
> > On Jan 5, 2018, at 9:36 AM, Alexander Dejanovski
> wrote:
> >
> > Hi Aleksey,
> >
> > ok we'll split the work and only d
ior of this patch but
> > I wanted to get some more feedback before committing to it. Are there any
> > objections to what Alex described?
> >
> > Regarding Mockito, I’ve been meaning to bring this up for a while, and
> I’m
> > a solid +1 on introducing it to hel
r of the change in behavior of this patch
> but
> > I wanted to get some more feedback before committing to it. Are there
> any
> > objections to what Alex described?
> >
> > Regarding Mockito, I’ve been meaning to bring this up for a while, and
> I’m
> > a soli
n order to write some tests
without starting the whole stack.
Thanks,
--
-----
Alexander Dejanovski
France
@alexanderdeja
Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com
pair in 3.11?
> So I can start "nodetool repair -pr" node after node or just "nodetool
> repair" on one node?
>
> Cheers,
> Michael
>
>
> On 14.09.2017 10:47, Alexander Dejanovski wrote:
> > Hi Micha,
> >
> > Are you running incrementa
---
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --
-
Alexander Dejanovski
France
@alexanderdeja
Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com
21 matches
Mail list logo
