Re: vnode random token assignment and replicated data antipatterns

> > Outside of rack awareness, would the next primary ranges take the replica > ranges? Yes. ​

Re: vnode random token assignment and replicated data antipatterns

Ahhh, the topology strategy does that. But if one were to maintain the same rack topology and was adding nodes just within the racks... Hm, might not be possible in new nodes. ALthough AWS "racks" are at the availability zone IIRC, so that would be doable. Outside of rack awareness, would the

Re: vnode random token assignment and replicated data antipatterns

That’s why you use a NTS + a snitch, it picks replaces based on rack awareness. > On Feb 20, 2018, at 9:33 AM, Carl Mueller > wrote: > > So in theory, one could double a cluster by: > > 1) moving snapshots of each node to a new node. > 2) for each snapshot moved,

Re: vnode random token assignment and replicated data antipatterns

So in theory, one could double a cluster by: 1) moving snapshots of each node to a new node. 2) for each snapshot moved, figure out the primary range of the new node by taking the old node's primary range token and calculating the midpoint value between that and the next primary range start token

vnode random token assignment and replicated data antipatterns

As I understand it: Replicas of data are replicated to the next primary range owner. As tokens are randomly generated (at least in 2.1.x that I am on), can't we have this situation: Say we have RF3, but the tokens happen to line up where: NodeA handles 0-10 NodeB handles 11-20 NodeA handlea