Re: Bootstrapping a new Node with Consistency=ONE

That makes sense. Thank you so much for pointing that out Alex. So long story short. Once I am up to the RF I actually want (RF3 per DC) and am just adding nodes for capacity joining the Ring will correctly work and no inconsistencies will exist. If I just change the RF the nodes don't have the

Re: Bootstrapping a new Node with Consistency=ONE

On Thu, Aug 3, 2017 at 9:33 AM, Daniel Hölbling-Inzko < daniel.hoelbling-in...@bitmovin.com> wrote: > No I set Auto bootstrap to true and the node was UN in nodetool status but > when doing a select on the node with ONE I got incomplete data. > What I think is happening here is not related to

Re: Bootstrapping a new Node with Consistency=ONE

No I set Auto bootstrap to true and the node was UN in nodetool status but when doing a select on the node with ONE I got incomplete data. Jeff Jirsa schrieb am Do. 3. Aug. 2017 um 09:02: > "nodetool status" shows node as UN (up normal) instead of UJ (up joining) > > What

Re: Bootstrapping a new Node with Consistency=ONE

"nodetool status" shows node as UN (up normal) instead of UJ (up joining) What you're describing really sounds odd. Something isn't adding up to me but I'm not sure why. You shouldn't be able to query it directly until its bootstrapped as far as I know Are you sure you're not joining as a seed

Re: Bootstrapping a new Node with Consistency=ONE

Thanks Jeff. How do I determine that bootstrap is finished? Haven't seen that anywhere so far. Reads via storage would be ok as every query would be checked by another node too. I was only seeing inconsistencies since clients went directly to the node with Consistency ONE Greetings Jeff Jirsa

Re: Bootstrapping a new Node with Consistency=ONE

By the time bootstrap is complete it should be as consistent as the source node - you can change start_native_transport to false to avoid serving clients directly (tcp/9042), but it'll still serve reads via the storage service (tcp/7000), but the guarantee is that data should be consistent by

Re: Bootstrapping a new Node with Consistency=ONE

only in this one case might that work (RF==N)

Re: Bootstrapping a new Node with Consistency=ONE

On Wed, Aug 2, 2017 at 10:53 AM, Daniel Hölbling-Inzko < daniel.hoelbling-in...@bitmovin.com> wrote: > > Any advice on how to avoid this in the future? Is there a way to start up > a node that does not serve client requests but does replicate data? > Would it not work if you first increase the

Re: Bootstrapping a new Node with Consistency=ONE

You can't just add a new DC and then tell their clients to connect to the new one (after migrating all the data to it obv.)? If you can't achieve that you should probably use GossipingPropertyFileSnitch.​ Your best plan is to have the desired RF/redundancy from the start. Changing RF in production

Re: Bootstrapping a new Node with Consistency=ONE

Thanks for the pointers Kurt! I did increase the RF to N so that would not have been the issue. DC migration is also a problem since I am using the Google Cloud Snitch. So I'd have to take down the whole DC and restart anew (which would mess with my clients as they only connect to their local

Re: Bootstrapping a new Node with Consistency=ONE

If you want to change RF on a live system your best bet is through DC migration (add another DC with the desired # of nodes and RF), and migrate your clients to use that DC. There is a way to boot a node and not join the ring, however I don't think it will work for new nodes (have not confirmed),

Bootstrapping a new Node with Consistency=ONE

Hi, It's probably a strange question but I have a heavily read-optimized payload where data integrity is not a big deal. So to keep latencies low I am reading with Consistency ONE from my Multi-DC Cluster. Now the issue I saw is that I needed to add another Cassandra node (for redundancy