Re: Token range redistribution

On 2018-04-19 21:20, kurt greaves wrote: That's assuming your data is perfectly consistent, which is unlikely. Typically that strategy is a bad idea and you should avoid it. Oh, it's definitely a bad idea. I was just pointing out that the OP might still be able to avoid data loss if they

Re: Token range redistribution

That's assuming your data is perfectly consistent, which is unlikely. Typically that strategy is a bad idea and you should avoid it. On Thu., 19 Apr. 2018, 07:00 Richard Gray, wrote: > On 2018-04-18 21:28, kurt greaves wrote: > > replacing. Simply removing and adding

Re: Token range redistribution

On 2018-04-18 21:28, kurt greaves wrote: replacing. Simply removing and adding back a new node without replace address will end up with the new node having different tokens, which would mean data loss in the use case you described. If you have replication factor N > 1, you haven't necessarily

Re: Token range redistribution

A new node always generates more tokens. A replaced node using replace_address[_on_first_boot] will reclaim the tokens of the node it's replacing. Simply removing and adding back a new node without replace address will end up with the new node having different tokens, which would mean data loss in

Token range redistribution

Hi, If i replace a node does it redistributes the token range or when the node again joins will it be allocated a new token range. Use case: I have booted a C* on AWS. I terminated a node and then boot a new node assigned it the same ip and made it join the cluster. In this case would the token