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).
gt; during the streaming a compaction kicked off which seemed very odd to us.
> "nodetool netstats" still reported tons of files that were not transferred
> yet. Is this normal that compaction might kick off during bootstrapping a
> new node. Our node still says "Joi
t were not transferred yet. Is this
normal that compaction might kick off during bootstrapping a new node. Our
node still says "Joining" in "nodetool netstats" as well. The ring does not
show the new node yet either. Lastly, "nodetool netstats" reports 0% on EVERY
sin
On Feb 12, 2013, at 18:58 , aaron morton wrote:
> Just checking if this sorted it's self out?
Well, partially. :) Situation at the moment:
>> 1) Is the new node not showing up in the "nodetool status" expected behavior?
Not showing still, don't know if should. :)
>> 2) Do I have to wait fo
Just checking if this sorted it's self out?
Cheers
-
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 10/02/2013, at 1:15 AM, Jouni Hartikainen
wrote:
> Hello all,
>
> I have a cluster of three nodes running 1.2.1 and I'd l
Hello all,
I have a cluster of three nodes running 1.2.1 and I'd like to increase the
capacity by adding a new node. I'm using virtual nodes with 256 tokens and
planning to use the same configuration for the new node as well.
My cluster looks like this before adding the new node:
Status=Up/Dow
ok, thank you for your time!
Cheers
On 03/16/2012 10:12 AM, aaron morton wrote:
I think your original plan is sound.
1. Up the RF to 4.
2. Add the node with auto_bootstrap true
3. Once bootrapping has finished the new node has all the data it needs.
4. Check for secondary index creation using
I think your original plan is sound.
1. Up the RF to 4.
2. Add the node with auto_bootstrap true
3. Once bootrapping has finished the new node has all the data it needs.
4. Check for secondary index creation using describe in the CLI to see which
are build. You can also see progress using node
ok, thank you both for the clarification. So the correct approach would
be to bootstrap the new node and run repair on each of the nodes in the
cluster.
I'm a bit puzzled though, I just tried to increase R to 3 in a cluster
with N=2. It serves reads and writes without issues CL.one. Is the
de
The documentation is correct.
I was mistakenly remembering discussions in the past about RF > #nodes.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 16/03/2012, at 4:34 AM, Doğan Çeçen wrote:
>> I'm not sure why this is not allowed. As l
> I'm not sure why this is not allowed. As long as I do not use CL.all there
> will be enough nodes available to satisfy the read / write (at least when I
> look at ReadCallback and the WriteResponseHandler). Or am I missing
> something here?
According to http://www.datastax.com/docs/1.0/cluster_a
Hi Aaron,
On 03/15/2012 10:52 AM, aaron morton wrote:
1. a running cluster of N=3, R=3
2. upgrade R to 4
You should not be allowed to set the RF higher than the number of nodes.
I'm not sure why this is not allowed. As long as I do not use CL.all
there will be enough nodes available to satisf
On Thursday 15 of March 2012, aaron morton wrote:
> > 1. a running cluster of N=3, R=3
> > 2. upgrade R to 4
>
> You should not be allowed to set the RF higher than the number of nodes.
I wonder why is that restriction ?
It would be easier to increase RF first (similar as having new node down),
> 1. a running cluster of N=3, R=3
> 2. upgrade R to 4
You should not be allowed to set the RF higher than the number of nodes.
I'm going to assume that clients on the web server only talk to the local
cassandra. So that when you add the new cassandra node it will not have any
clients until yo
Hi,
I'm using cassandra (1.0.8) embedded in the same jvm as a
webapplication. All data is available on all nodes (R = N), read /
write CL.ONE.
Is it correct to assume in the following scenario that the newly added
node has all data locally and that secondary indexes are fully created
afte
26 matches
Mail list logo
