, March 7, 2023 22:37
To: dev@cassandra.apache.org
Subject: Re: Degradation of availability when using NTS and RF > number of racks
I am forwarding the message Ben Slater wrote me personally and asked me to post
it. He has some problems with the subscription to this mailing list with his
email.
V
high RF on system auth was more about replicating to lots of
nodes than distributing across racks
Cheers
Ben
From: Paulo Motta
Sent: Tuesday, March 7, 2023 21:43
To: dev@cassandra.apache.org
Subject: Re: Degradation of availability when using NTS and RF &
the saying goes there is no silver bullet. If we decide to
>> implement that new strategy, we would probably emit warnings anyway on NTS
>> but it would be already done so just new strategy would be provided.
>> >>
>> >>
; Sent: Monday, March 6, 2023 17:48
>> To: dev@cassandra.apache.org
>> Subject: Re: Degradation of availability when using NTS and RF > number of racks
>>
>> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sen
___
From: Jeremiah D Jordan
Sent: Tuesday, March 7, 2023 19:31
To: dev@cassandra.apache.org
Subject: Re: Degradation of availability when using NTS and RF > number of racks
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender
t; offered ones. As the saying goes there is no silver bullet. If we decide
>> >> to implement that new strategy, we would probably emit warnings anyway on
>> >> NTS but it would be already done so just new strategy would be provided.
>> >>
>> >> _
>> 100% bullet proof solution over time we might choose some approach from the
>> offered ones. As the saying goes there is no silver bullet. If we decide to
>> implement that new strategy, we would probably emit warnings anyway on NTS
>> but it would be already done so
______________
> >> From: Paulo Motta
> >> Sent: Monday, March 6, 2023 17:48
> >> To: dev@cassandra.apache.org
> >> Subject: Re: Degradation of availability when using NTS and RF > number
> of racks
> >>
> >> NetApp Securit
nt that new strategy, we would probably emit warnings anyway on NTS
>> but it would be already done so just new strategy would be provided.
>>
>>
>> From: Paulo Motta
>> Sent: Monday, March 6, 2023 17:48
>> To: dev@cassandr
@cassandra.apache.org
> Subject: Re: Degradation of availability when using NTS and RF > number of
> racks
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
>
>
&g
Subject: Re: Degradation of availability when using NTS and RF > number of racks
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
It's a bit unfortunate that NTS does not maintain the
It's a bit unfortunate that NTS does not maintain the ability to lose a
rack without loss of quorum for RF > #racks > 2, since this can be easily
achieved by evenly placing replicas across all racks.
Since RackAwareTopologyStrategy is a superset of NetworkTopologyStrategy,
can't we just use the ne
A huge number of people use this legal and unsafe combination - like anyone
running RF=3 in AWS us-west-1 (or any other region with only 2 accessible
AZs), and no patch is going to suddenly make that safe, and banning it
hurts users a lot.
If we're really going to ship a less-bad version of this,
1) It does seem a like a big footgun. I think it violates the principle of
least surprise if someone has configured NTS thinking that they are
improving availability
2) I don't know that we want to ban it outright, since maybe there's a case
for someone to be using a different CL that would be OK w
Modifying NTS in place would not be possible if it changes rack placement in a
way that breaks existing clusters on upgrade. A strategy introducing a change
to placement like this would need a new name. A new strategy would be fine in
trunk.
Logging a warning seems appropriate if RF > rack coun
15 matches
Mail list logo