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 dat
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 the
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 you're describing really
"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
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 sc
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 th
only in this one case might that work (RF==N)
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 RF
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
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 DC).
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), a
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 reasons).
12 matches
Mail list logo