Hi all -
We currently have a single cassandra cluster that is dedicated to a
relatively narrow purpose, with just 2 tables. Soon we will need cassandra
for another, unrelated, system, and my debate is whether to just add the
new tables to our existing cassandra cluster or whether to spin up an
://linkedin.com/in/carlosjuzarterolo*
Mobile: +31 6 159 61 814 | Tel: +1 613 565 8696 x1649
www.pythian.com
On Thu, Apr 2, 2015 at 3:06 PM, Ian Rose ianr...@fullstory.com wrote:
Hi all -
We currently have a single cassandra cluster that is dedicated to a
relatively narrow purpose, with just 2 tables
Howdy -
I'd like to (a) monitor how long my repairs are taking, and (b) know when a
repair is finished so that I can take some kind of followup action. What's
the best way to tackle either or both of these?
Some potentially relevant details:
- running community apache cassandra (not DSE)
-
Thanks Jan, although I'm a bit unsure of the details. It looks like when
you run a repair this actually occurs over several sessions. e.g. in
your example above there are 2 different repair session [...] finished
lines. So does it makes sense that I would want to measure between when I
first
When I see a warning like Read 9 live and 5769 tombstoned cells in ...
etc is there a way for me to see the partition key that this query was
operating on?
The description in the original JIRA ticket (
https://issues.apache.org/jira/browse/CASSANDRA-6042) reads as though
exposing this information
ticket for this improvement at
https://issues.apache.org/jira/browse/CASSANDRA-8561
On Wed, Jan 21, 2015 at 4:55 PM, Ian Rose ianr...@fullstory.com wrote:
When I see a warning like Read 9 live and 5769 tombstoned cells in ...
etc is there a way for me to see the partition key that this query
Howdy all,
Our use of cassandra unfortunately makes use of lots of deletes. Yes, I
know that C* is not well suited to this kind of workload, but that's where
we are, and before I go looking for an entirely new data layer I would
rather explore whether C* could be tuned to work well for us.
.
Robert
On Dec 16, 2014, at 8:22 AM, Ian Rose ianr...@fullstory.com wrote:
Howdy all,
Our use of cassandra unfortunately makes use of lots of deletes. Yes, I
know that C* is not well suited to this kind of workload, but that's where
we are, and before I go looking for an entirely new
*From:* Ian Rose ianr...@fullstory.com
*Sent:* Tuesday, December 16, 2014 10:22 AM
*To:* user user@cassandra.apache.org
*Subject:* does consistency=ALL for deletes obviate the need for
tombstones?
Howdy all,
Our use of cassandra unfortunately makes use of lots of deletes. Yes, I
know
Try `nodetool clearsnapshot` which will delete any snapshots you have. I
have never taken a snapshot with nodetool yet I found several snapshots on
my disk recently (which can take a lot of space). So perhaps they are
automatically generated by some operation? No idea. Regardless, nuking
those
...@gmail.com
wrote:
I have observed this kind of situation with 0 agents connected.
Restarting the agents always helped so far. By the way, check the agent's
logs and opscenterd logs, there may be some clues there.
On Tue, Dec 2, 2014 at 4:59 PM, Ian Rose ianr...@fullstory.com wrote:
Hi all
Hi all -
Just getting started setting up OpsCenter today. I have a 3 node cassandra
cluster and (afaict) the agent installed and running happily on all 3
nodes. I also have OpsCenter up and running on a 4th node. I do not have
SSL enabled between these nodes.
In the OpsCenter interface, I see
Hi -
We are running a small 3-node cassandra cluster on Google Compute Engine.
I notice that our machines are reporting (via a collectd agent, confirmed
by `top`) a significant amount of cpu time in the NICE state. For example,
one of our machines is a n1-highmem-4 (4 cores, 26 GB RAM). Here is
:
Hello,
AFAIK Compaction threads run with a lower affinity, I believe that will
show up as “niced”..
Regards,
Andras
From: Ian Rose ianr...@fullstory.com
Reply-To: user user@cassandra.apache.org
Date: Wednesday 8 October 2014 17:29
To: user user@cassandra.apache.org
Subject: significant
I assume it's a hash to detect read/write races. As an example:
1. actor 1 reads key = (1, 'whatever') and gets value = V0
2. actor 2 writes to key (1, 'whatever') with new value V1
3. actor 1 writes an anticolumn with key = (0, 'whatever') and value =
md5(V0)
4. later, if someone wants to read
:00Pacific Daylight Time | 1.3
1 | 2014-05-03 00:00:00Pacific Daylight Time | 1.4
(3 rows)
cqlsh:playlist
On Tue, Aug 26, 2014 at 12:33 PM, Ian Rose ianr...@fullstory.com wrote:
Unfortunately, no. I've read that and the solution presented only works
in limited scenarios. Using
Is it possible in CQL to create a table that supports dynamic column names?
I am using C* v2.0.9, which I assume implies CQL version 3.
This page appears to show that this was supported in CQL 2 with the 'with
comparator' and 'with default_validation' options but that CQL 3 does not
support
26, 2014 at 1:12 PM, Ian Rose ianr...@fullstory.com wrote:
Is it possible in CQL to create a table that supports dynamic column
names? I am using C* v2.0.9, which I assume implies CQL version 3.
This page appears to show that this was supported in CQL 2 with the 'with
comparator
Confusingly, it appears to be the presence of an index on int_val that is
causing this timeout. If I drop that index (leaving only the index on
foo_name) the query works just fine.
On Tue, Aug 12, 2014 at 10:25 PM, Ian Rose ianr...@fullstory.com wrote:
Hi -
I am currently running a single
not give any guarantee about performance of such query.
As Robert Coli used to say on this list, ALLOW FILTERING is synonym to
PROBABLY TIMEOUT :D
On Wed, Aug 13, 2014 at 2:56 PM, Ian Rose ianr...@fullstory.com wrote:
Confusingly, it appears to be the presence of an index on int_val
that this hasn't been fixed in a recent version, but if you are using
a recent release (say 2.0.9), then please do open a JIRA ticket with your
reproduction steps.
On Wed, Aug 13, 2014 at 4:25 AM, Ian Rose ianr...@fullstory.com wrote:
Hi -
I am currently running a single Cassandra node on my local dev
, that's the main reason they implement a distributed secondary
index. There is no free lunch though. What you gain in term of control and
tuning with the manual index, you loose on the load distribution side.
On Mon, Aug 11, 2014 at 11:17 PM, Ian Rose ianr...@fullstory.com wrote:
Hi DuyHai
Hi -
I am currently running a single Cassandra node on my local dev machine.
Here is my (test) schema (which is meaningless, I created it just to
demonstrate the issue I am running into):
CREATE TABLE foo (
foo_name ascii,
foo_shard bigint,
int_val bigint,
PRIMARY KEY ((foo_name,
or 1 minute, depending on the insertion rate.
On Sun, Aug 10, 2014 at 10:02 PM, Ian Rose ianr...@fullstory.com wrote:
Hi Mark -
Thanks for the clarification but as I'm not too familiar with the nuts
bolts of Cassandra I'm not sure how to apply that info to my current
situation
Hi -
On this page (
http://www.datastax.com/documentation/cql/3.0/cql/ddl/ddl_when_use_index_c.html),
the docs state:
Do not use an index [...] On a frequently updated or deleted column
and
*Problems using an index on a frequently updated or deleted column*¶
-datasets
[2] https://issues.apache.org/jira/browse/CASSANDRA-6042
[3] https://issues.apache.org/jira/browse/CASSANDRA-6117
[4]
https://github.com/jbellis/cassandra/blob/4ac18ae805d28d8f4cb44b42e2244bfa6d2875e1/conf/cassandra.yaml#L407-L417
On Sun, Aug 10, 2014 at 7:19 PM, Ian Rose ianr
26 matches
Mail list logo
