Just as a heads-up, #cassandra in freenode IRC is pretty active. You might have
more luck there
> On 15 Jul 2016, at 08:11, denish patel wrote:
>
> Hello,
>
> I have started Slack channel to discuss Cassandra.
> The purpose of this channel to use existing slack
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
We're going to need *way* more information than this
On 03 Feb 2011, at 20:03, ruslan usifov wrote:
Hello
Why i can get Unavalible Exception on live cluster (all nodes is up and never
shutdown)
PS: v 0.7.0
I'm upgrading an 0.6 cluster to 0.7 in a testing environment. In cleaning up
one of the nodes I get the exception below. Googling around seems to reveal
people having trouble with it caused by too-small heap sizes but that doesn't
look to be what's going on here. Am I missing something obvious?
I'd like to move a CF from one keyspace into another. I'm running 0.6.8. Is
this just a matter of draining the nodes, taking down the cluster, updating the
schema in storage-conf.xml, and moving the files themselves? Is there an even
niftier trick that I can without taking down the cluster?
So with the row cache, that first node (the primary replica) is the one that
has that row cached, yes?
No, it's the closest node as determined by snitch.sortByProximity.
And with the default snitch, rack-unaware placement, random partitioner, and
all nodes up, that's the primary replica,
If I go to fetch some row given the rack-unaware placement strategy, the
default snitch and CL==ONE, the node that is asked is the first node in the
ring with the datum that is currently up, then a checksum is sent to the
replicas to trigger read repair as appropriate. So with the row cache,
[r...@calculus apache-cassandra-0.6.1]# bin/cassandra -f
Can't start up: not enough memory
My guess is that you don't have enough memory
I'm having trouble visualising how to maintain a secondary index on a mutable
column. For instance, given some objects and the number that we have in
inventory:
widget1: { count = 0, colour = blue }
widget2: { count = 5, colour = red }
widget3: { count = 8, colour = green }
widget4: { count =
Is it possible to have Cassandra instances that serve only as proxies to the
rest of the cluster, but have no storage themselves? Maybe with a keyspace
length of 0?
10 matches
Mail list logo