Any insights on vnodes, one month after my original post ?
2013/5/16 Alain RODRIGUEZ
> Hi,
>
> Adding vnodes is a big improvement to Cassandra, specifically because we
> have a fluctuating load on our Cassandra depending on the week, and it is
> quite annoying to add some nodes for one week or
On 10 June 2013 22:00, Emalayan Vairavanathan wrote:
b) Will Cassandra automatically take care of removing
> obsolete keys in future ?
>
In a future version Cassandra should automatically clean up for you:
https://issues.apache.org/jira/browse/CASSANDRA-5051
Right now thoug
We are currently running on 1.1.10 and planning to migrate to a higher
version 1.2.4.
The question pertains to tweaking all the knobs to reduce GC related issues
( we have been fighting a lot of really bad GC issues on 1.1.10 and met with
little
success all the way using 1.1.10)
Taking into cons
I am using cassandra 1.2.6 in cluster with a single node. I am trying to rename
the cluster using the instructions in:
Cassandra clustername mismatch
After doing all the steps indicate I continue with the same error when I start
cassandra after change the cassandra.yaml file
Do anyone Know if
The cluster name is read from the yaml file the first time the server starts
and stored in the system tables, these are in the local CF in the system KS.
If this is test system just blow away the data for the CF or truncate it.
Cheers
-
Aaron Morton
Freelance Cassandra Consulta
> *thrift_framed_transport_size_in_mb & thrift_max_message_length_in_mb*
This control the max size of a bugger allocated by thrift when processing
requests / responses. The buffers are not pre allocated, but once they are
allocated they are not returned. So it's only an issue if have lots of clie
> Even more if we could automate some up-scale thanks to AWS alarms, It would
> be awesome.
I saw a demo for Priam (https://github.com/Netflix/Priam) doing that at netflix
in March, not sure if it's public yet.
> Are the vnodes feature and the tokens =>vnodes transition safe enough to go
> liv
Can't find any promotion failure.
In system.log this is what I get:
INFO [ScheduledTasks:1] 2013-06-17 08:13:47,490 GCInspector.java (line
122) GC for ParNew: 145189 ms for 1 collections, 225905072 used; max is
4114612224
INFO [ScheduledTasks:1] 2013-06-17 08:13:47,490 StatusLogger.java (line
57
> I also am not seeing anything in the nodes log files to suggest errors during
> streaming or leaving.
You should see a log message saying "DECOMMISSIONED" when the process
completes.
What does nodetool status say?
> What suggestions does anyone have on getting this node removed from my ring
Thanks Aaron for the insight.
One quick question:
>The buffers are not pre allocated, but once they are allocated they are
>not returned. So it's only an issue if have lots of clients connecting
>and reading a lot of data.
So to understand you correctly, the buffer is allocated per client
connect
Mostly for fun, I wanted to throw this out there...
We are undergoing a security audit for our platform (C* + Elastic Search +
Storm). One component of that audit is susceptibility to SQL injection. I
was wondering if anyone has attempted to construct a SQL injection attack
against Cassandra? I
Hello,
I'm seeing a strange problem with a 2-node Cassandra test deployment, where it
seems that data isn't being replicated among the nodes as I would expect. I
suspect this may be a configuration issue of some kind, but have been unable to
figure what I should change.
The setup is as follow
GC logging is not in system.log. But in the following file.
JVM_OPTS="$JVM_OPTS -Xloggc:/var/log/cassandra/gc-`date +%s`.log"
At least, no GC logs are shown in your post.
On Tue, Jun 18, 2013 at 5:05 PM, Joel Samuelsson
wrote:
> Can't find any promotion failure.
>
> In system.log this is what
If you're not careful, then "CQL injection" is possible.
Say you naively build you query with
"UPDATE foo SET col='" + user_input + "' WHERE key = 'k'"
then if user_input is "foo' AND col2='bar", your user will have overwritten
a column it shouldn't have been able to. And something equivalent in
On Mon, Jun 17, 2013 at 3:37 PM, Franc Carter wrote:
> On Mon, Jun 17, 2013 at 3:28 PM, Wei Zhu wrote:
>
>> default value of 5MB is way too small in practice. Too many files in one
>> directory is not a good thing. It's not clear what should be a good number.
>> I have heard people are using 50MB
Our experience shows that write load (memtables) impacts ParNew GC most. More
writes, more frequent ParNew GC. Time of ParNew GC depends on how many writes
was made during cycle between ParNew GC's and size of NEW_HEAP (young gen).
Basicly ParNew GC itself takes longer when more objects have to
Perfect. Thanks Sylvain. That is exactly the input I was looking for, and
I agree completely.
(t's easy enough to protect against)
As for the thrift side (i.e. using Hector or Astyanax), anyone have a crafty
way to inject something?
At first glance, it doesn't appear possible, but I'm not 100%
Never saw "decommissioned" in the logs, status continues to says "UL" on
status.
Removenode sounds like its likely to get the job done for us at this point.
Thanks.
David
On Tue, Jun 18, 2013 at 3:10 AM, aaron morton wrote:
> I also am not seeing anything in the nodes log files to suggest err
I see an issues when I run high traffic to the Cassandra nodes, the heap
gets full to about 94% (which is expected) but the thing that confuses me
is that the heap usage never goes down after the traffic is stopped
(at-least, it appears to be so) . I kept the nodes up for a day after
stopping the t
Yes, like I said, the only relevant output from that file was:
2013-06-17T08:11:22.300+: 2551.288: [GC 870971K->216494K(4018176K),
145.1887460 secs]
2013/6/18 Takenori Sato
> GC logging is not in system.log. But in the following file.
>
> JVM_OPTS="$JVM_OPTS -Xloggc:/var/log/cassandra/gc-`d
Is your young generation size set to 4GB? Can you paste the output of ps
-ef|grep cassandra ?
On Tue, Jun 18, 2013 at 8:48 AM, Joel Samuelsson
wrote:
> Yes, like I said, the only relevant output from that file was:
> 2013-06-17T08:11:22.300+: 2551.288: [GC 870971K->216494K(4018176K),
> 145.18
Cassaforte [1] is a Clojure client for Cassandra built around CQL 3.0 and
focusing
on ease of use. It's built on top of the new DataStax Java driver [2] and
supports
all the major features you'd expect from a data store client:
* Connection to a single node or a cluster
* All CQL 3.0 operations
Hi All,
I have a cluster of 5 nodes with C* 1.2.4.
Each node has 4 disks 1 TB each.
I see a lot of dropped messages after it stores 400 GB per disk. (1.6 TB
per node).
The recommendation was 500 GB max per node before 1.2. Datastax says that
we can store terabytes of data per node with 1.2.
On Tue, Jun 18, 2013 at 8:25 AM, srmore wrote:
> I see an issues when I run high traffic to the Cassandra nodes, the heap
> gets full to about 94% (which is expected)
Which is expected to cause GC failure? ;)
But seriously, the reason your node is unable to GC is that you have
filled your heap t
Can you expand on the reasoning behind this? I was bitten by this yesterday when
trying to change the cluster name -- I thought I could just change it in the
cassandra.yaml and be done with it but cassandra wouldn't start because of this
error.
What's the process when it's not a test system (mine
Thanks Rob,
But then shouldn't JVM C G it eventually ? I can still see Cassandra alive
and kicking but looks like the heap is locked up even after the traffic is
long stopped.
nodetool -h localhost flush didn't do much good.
the version I am running is 1.0.12 (I know its due for a upgrade but gott
On Tue, Jun 18, 2013 at 10:20 AM, Faraaz Sareshwala
wrote:
> Can you expand on the reasoning behind this?
https://issues.apache.org/jira/browse/CASSANDRA-769
In various versions of Cassandra (including current, IIRC?) you can
change the cluster name via manual edits to the system keyspace.
If y
On Tue, Jun 18, 2013 at 10:33 AM, srmore wrote:
> But then shouldn't JVM C G it eventually ? I can still see Cassandra alive
> and kicking but looks like the heap is locked up even after the traffic is
> long stopped.
No, when GC system fails this hard it is often a permanent failure
which requir
Cassandra doesn't do async replication like HBase does.You can run nodetool
repair to insure the consistency.
Or you can increase your Read or Write consistency. As long as R + W > RF, you
have strong consistency. In your case, you can use CL.TWO for either read and
write.
-Wei
- Origi
On Tue, Jun 18, 2013 at 11:36 AM, Wei Zhu wrote:
> Cassandra doesn't do async replication like HBase does.You can run nodetool
> repair to insure the consistency.
While this answer is true, it is somewhat non-responsive to the OP.
If the OP didn't see timeout exception, the theoretical worst cas
Thank you all.
I have two more question.
1) Is there any implication in running nodetool repair immediately after
bringing a new node up (before key migration process is completed) ?
Will it cause some race conditions ? Or will it result in some part of
the space never be reclaimed ?
On Sat, Jun 15, 2013 at 11:49 AM, Franc Carter wrote:
> On Sat, Jun 15, 2013 at 8:48 AM, Robert Coli wrote:
>
>> On Wed, Jun 12, 2013 at 3:26 PM, Franc Carter
>> wrote:
>> > We are running a test system with Leveled compaction on Cassandra-1.2.4.
>> > While doing an initial load of the data one
Manual compaction for LCS doesn't really do much. It certainly doesn't
compact all those little files into bigger files. What makes you think
that compactions are not occurring?
-Bryan
On Tue, Jun 18, 2013 at 3:59 PM, Franc Carter wrote:
> On Sat, Jun 15, 2013 at 11:49 AM, Franc Carter
> wr
On Wed, Jun 19, 2013 at 9:34 AM, Bryan Talbot wrote:
> Manual compaction for LCS doesn't really do much. It certainly doesn't
> compact all those little files into bigger files. What makes you think
> that compactions are not occurring?
>
>
Yeah, that's what I thought, however:-
nodetool compac
Hello,
Can anyone suggest a good/popular Unit Test tools/frameworks/utilities out
there for unit testing Cassandra stores? I am looking for testing from
performance/load and monitoring perspective. I am using 1.2.
Thanks a lot.
Regards,
Shahab
Cem hi,
as per http://wiki.apache.org/cassandra/FAQ#dropped_messages
Internode messages which are received by a node, but do not get not to be
processed within rpc_timeout are dropped rather than processed. As the
coordinator node will no longer be waiting for a response. If the Coordinator
no
36 matches
Mail list logo