A bit of organization - I've created
https://issues.apache.org/jira/browse/CASSANDRA-18300 epic to track tickets
related to the downgradability. Please add the tickets you are aware of.
thanks
- - -- --- - -
Jacek Lewandowski
czw., 23 lut 2023 o 17:47 Benedict napisał(a
Sorry, I realized that when I started the discussion I probably did not
frame it enough as I see that it is now going into different directions.
The concerns I am seeing are:
1) A too small amount of time between releases is inefficient from a
development perspective and from a user perspective. F
Hi all,
some time ago we identified an issue with NetworkTopologyStrategy. The problem
is that when RF > number of racks, it may happen that NTS places replicas in
such a way that when whole rack is lost, we lose QUORUM and data are not
available anymore if QUORUM CL is used.
To illustrate thi
On Sun, Mar 5, 2023 at 11:00 PM Paulo Motta wrote:
> I found this a bit surprising, since I would expect a snapshot with the same
> name on different tables to represent the same logical snapshot taken at the
> same point-in-time.
I would expect this too, 100%.
> This affects the design of the
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
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
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,
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
