I'm please to share a framework for running Cassandra stress tests on EC2.
https://github.com/cloudius-systems/ansible-cassandra-cluster-stress
The framework is a collection of Ansible playbooks and scripts, allowing to:
- Create a Cassandra cluster (setting server type, version, etc)
- Launch any
I want to start using vnodes in my cluster. To do so, I've set up a new
data center with the same number of nodes as the existing one, as described
in
http://docs.datastax.com/en/cassandra/2.0/cassandra/configuration/configVnodesProduction_t.html.
The new DC is in the same physical location as the
Hi All,
I have a use-case where in I want to execute query on my cassandra table with
different where clauses.
Two approaches know to me is :-
Creating secondary index
But to my understanding, query on secondary index will be slow.
Creating multiple tables with same data but different primary ke
Hey Tom,
What's your replication strategy look like? When your new nodes join the
ring, can you verify that they show up under a new DC and not as part of
the old?
--Bryan
On Thu, Sep 3, 2015 at 11:27 AM, Tom van den Berge <
tom.vandenbe...@gmail.com> wrote:
> I want to start using vnodes in my
Hi Bryan,
I'm using the PropertyFileSnitch, and it contains entries for all nodes in
the old DC, and all nodes in the new DC. The replication factor for both
DCs is 1.
With the first approach I described, the new nodes join the cluster, and
show up correctly under the new DC, so all seems to be f
This all seems fine so far. Are you able to see what errors are being
returned?
We had a similar issue where one of our secondary, less used keyspaces was
on a replication strategy that was not DC-aware, which was causing errors
about being unable to satisfy LOCAL_ONE and LOCAL_QUORUM quoroum leve
Hi Bryan,
It does not generate any errors. A query for a specific row simply does not
return the row if it is sent to a node in the new DC. This makes sense,
because the node is still empty.
On Thu, Sep 3, 2015 at 9:03 PM, Bryan Cheng wrote:
> This all seems fine so far. Are you able to see wha
Hey Tom,
I'd recommend you enable tracing and do a few queries in a controlled
environment to verify that queries are being routed to your new nodes.
Provided you have followed the procedure outlined above (specifically, have
set auto_bootstrap to false in your new cluster), rebuild has not been r
On Thu, Sep 3, 2015 at 12:25 PM, Bryan Cheng wrote:
> I'd recommend you enable tracing and do a few queries in a controlled
> environment to verify that queries are being routed to your new nodes.
> Provided you have followed the procedure outlined above (specifically, have
> set auto_bootstrap t
Thanks for your help so far!
I have some problems trying to understand the jira mentioned by Rob :(
I'm currently trying to set up the first node in the new DC with
auto_bootstrap = true. The node then becomes visible with status "joining",
which (hopefully) prevents other DCs from sending querie
On fresh install of Cassandra what's the best approach to start using
incremental repair from the get go (I'm using LCS) ?
Run nodetool repair -inc after inserting a few rows , or we still need to
follow the migration procedure with sstablerepairedset ?
>From the documentation "... If you use the
Given this table:
CREATE TABLE import_file (
roll int,
type text,
id timeuuid,
data text,
PRIMARY KEY ((roll), type, id)
)
This should be possible:
SELECT data FROM import_file WHERE roll = 1 AND type = 'foo' ORDER BY id DESC;
but it results in the following error:
Bad Request: Order
Limitation, not bug. The reason ?
On disk, data are sorted by type first, and FOR EACH type value, the data
are sorted by id.
So to do an order by Id, C* will need to perform an in-memory re-ordering,
not sure how bad it is for performance. In any case currently it's not
possible, maybe you shoul
If you only specify the partition key, and none of the clustering columns, you
can order by in either direction:
SELECT data FROM import_file WHERE roll = 1 order by type;
SELECT data FROM import_file WHERE roll = 1 order by type DESC;
These are both valid. Seems like specifying the prefix of th
It's normal, type is the FIRST clustering column so on disk, data are
sorted first by "type" naturally. C* does not have to perform any sorting
in memory.
And when you're using "order by type DESC", it's still not sorted in
memory, C* is just doing a backward-scan on disk starting from the
"bigges
You should be able to execute the following
SELECT data FROM import_file WHERE roll = 1 AND type = 'foo' ORDER BY type, id
DESC;
Essentially the order by clause has to specify the clustering columns in order
in full. It doesn't by default know that you have already essentially filtered
by type
After enabling that option, I'm seeing errors like this on the node I
can't connect to.
Sep 04, 2015 2:35:48 AM sun.rmi.server.UnicastServerRef logCallException
FINE: RMI TCP Connection(4)-127.0.0.1: [127.0.0.1] exception:
javax.management.InstanceNotFoundException:
org.apache.cassandra.metrics:t
I figured this one out. As it turns out, the nodes that I couldn't
connect to, had the hostname set to 127.0.1.1. The listen IP is *not*
that IP.
Thanks for the logging tip, it helped track it down.
On Thu, Sep 3, 2015 at 10:43 PM, Jason Lewis wrote:
> After enabling that option, I'm seeing er
I should probably add.. /etc/hosts had the hostname set to 127.0.1.1.
On Thu, Sep 3, 2015 at 11:00 PM, Jason Lewis wrote:
> I figured this one out. As it turns out, the nodes that I couldn't
> connect to, had the hostname set to 127.0.1.1. The listen IP is *not*
> that IP.
>
> Thanks for the lo
19 matches
Mail list logo
