Hi Alain
- Over use the cluster was one thing which I was thinking about, and I
have requested two new nodes (anyway it was something already planned). But the
pattern of nodes with high CPU load is only visible in 1 or two of the nodes,
the rest are working correctly. That made me th
Hi daemeon
We have check network and it is ok, in fact the nodes are connecting between
themselves with a dedicated network.
From: daemeon reiydelle [mailto:daeme...@gmail.com]
Sent: maandag 4 april 2016 18:42
To: user@cassandra.apache.org
Subject: Re: all the nost are not reacheable when runnin
Hello,
I noticed the following change in behavior while migrating from 2.0.11:
Elements of the clustering key seems to not be secondary indexable anymore.
Anyone could give me an insight about this issue? Or point me to documents
relative to this evolution?
There is a sample table with some data:
I'm surprised this would have fall through the cracks but that certainly
look like a regression (a bug). If you can reproduce on 3.0.4 (just to make
sure we haven't fixed it recently), then please open a ticket in
https://issues.apache.org/jira/browse/CASSANDRA/ with your repro steps.
On Tue, Apr
>
> Over use the cluster was one thing which I was thinking about, and I
> have requested two new nodes (anyway it was something already planned). But
> the pattern of nodes with high CPU load is only visible in 1 or two of the
> nodes, the rest are working correctly. That made me think that addin
What do you mean by “automatically starts syncing?” Are you seeing streaming of
existing data or just the addition of new, incoming data? Do you have repairs
running as part of your automated maintenance, perhaps?
I would expect that new, incoming data would be replicated to the new DC after
th
Hi Vijay.
After completing step 7.a (which is altering keyspace with desired
> replication factor for new DC) data automatically starts syncing from
> existing DC to new DC
>
My guess: what you are seeing is not data syncing. Well it is, but not old
data being streamed but new writes being replic
hi;
we are upgrading our cluster from apache-cassandra 2.0.14 to 2.0.17. We
have been facing SYN flooding issue (port 9042) in our current version of
Cassandra at times. We are hoping to tackle the SYN flooding issues with
the following attributes in the YAML file for 2.0.17
native_transport_max
Why is this a requirement? Honestly I don't know why you would do this.
On Sat, Apr 2, 2016 at 8:06 PM Mukil Kesavan
wrote:
> Hello,
>
> We currently have 3 Cassandra servers running in a single datacenter with
> a replication factor of 3 for our keyspace. We also use the SimpleSnitch
> wiith D
Many C* versions back I did this by writing a custom snitch. This was to
maximise use of the row cache but had the effect of pinning requests for a key
to a given server. It sounds like you want to do the same thing but ignoring
the key. In more modern reversions I believe this may be done as a
Aside from Jon's "why" question, I would point out that this only really
works because you are running a 3 node cluster with RF=3. If your cluster
is going to grow, you can't guarantee that any one server would have all
records. I'd be pretty hesitant to put an invisible constraint like that on
a c
Yep - Steve hit the nail on the head. The odds of hitting the right server
with "sticky routing" goes down as your cluster size increases. You end up
adding extra network hops instead of using token aware routing.
Unless you're trying to do a coordinator tier (and you're not, according to
your o
Jon and Steve:
I don't understand your point. The TokenAwareLoadBalancer identifies the
nodes in the cluster that own the data for a particular token and route
requests to one of them. As I understand it, the OP wants to send requests
for a particular token to the same node every time (assuming it
Once a while the question about table count rises in this list. The most
recent is
https://groups.google.com/forum/#!topic/nosql-databases/IblAhiLUXdk
In short C* is not designed to scale with the table count. For one each
table/CF has some fixed memory footprint on *ALL* nodes. The consensus is
y
Jim, that's not what he asked. He asked for the equivalent of a load
balancer with sticky sessions.
On Tue, Apr 5, 2016 at 2:24 PM Jim Ancona wrote:
> Jon and Steve:
>
> I don't understand your point. The TokenAwareLoadBalancer identifies the
> nodes in the cluster that own the data for a parti
John and Steve,
We use QUORUM consistency for both READS and WRITES. So we won't have the
problem of having to pick the right server. The real reason we have this
requirement is because we run in a sometimes overloaded virtualized
environment that causes the servers to have non-trivial time drifts
Hi Micky,
The only issues I've seen personally with dropped updates due to even small
amounts of time skew were ones I was able to fix by the judicious use of
BatchStatements. This was particularly true with counter fields in the 2.0
release (i.e. before counters were fixed), but would also happen
What is the nature of these tenants? Are they each creating their own data
models? Is there one central authority that will approve of all data models
and who can adjust the cluster configuration to support those models?
Generally speaking, multi-tenancy is an anti-pattern for Cassandra and for
mo
Thanks Kai,
One approach discussed in that post is about disabling slab allocation.
What are the consequences except for lower GC performance?
Kai Wang 于2016年4月6日周三 上午5:40写道：
> Once a while the question about table count rises in this list. The most
> recent is
> https://groups.google.com/forum
Hi Jack,
Thanks for the reply.
Each tenant will has around 50-100 tables for their applications. probably
log collection, probably account table, it's not fixed and depends on
tenants' need.
There will be a team in charge of helping tenant to do data modeling and
access patterns. Tenants will no
Thanks Alain and Sean, your detailed explanation answers my question.
Yes, nodetool status reflects new DC and nodetool netstats says not "No
Streams".
My all writes going to old DC with local_quorum. Yes this new data might be
getting synced into new DC (repair was not running anywhere).
I will p
With small data size and unknown access pattern, any particular reason to
choose C*? It sounds like a relational database fits better.
On Tue, Apr 5, 2016 at 11:40 PM, jason zhao yang <
zhaoyangsingap...@gmail.com> wrote:
> Hi Jack,
>
> Thanks for the reply.
>
> Each tenant will has around 50-100
We are having performance problems with our cluster regarding to timeouts when
repairs are running or massive deletes. One of the advice I received was update
our casssandra version from 2.0.17 to 2.2. I am draining one of the nodes to
start the upgrade and the drain is running now for two days.
23 matches
Mail list logo
