Hi, all,
We are trying to reason the possible scenarios when a C*(v1.x) cluster
connection keeps flapping in production. (Two node cluster, each node keeps
marking the other node DOWN but came back UP within seconds; multiple times a
day) We have checked the load on the cluster i- very light a
> Is this documented somewhere (in the README.txt, etc.)? It is super
useful for first-time Ant users like myself to know this upfront.
It's documented in the HowToContribute link you posted initially:
https://wiki.apache.org/cassandra/RunningCassandraInIDEA ;)
2016-03-23 2:23 GMT-03:00 Nishant K
OK. Thanks.
On Tue, Mar 22, 2016 at 12:56 PM Alex Popescu wrote:
> Hi Thunder,
>
> This would be better sent to the Java mailing list
> https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user.
> A quick search revealed https://datastax-oss.atlassian.net/browse/JAVA-603
> whi
Doh! Didn't look that far down :)
Maybe the "IDE" section should be moved to the top in the wiki? That way,
it becomes more visible? (assuming most contributors are interested in
setting up the IDE before running ant test, ant codecoverage, etc.)
Best Regards,
Nishant Kelkar
On Wednesday, March
Is this from the 1.1 line, perhaps? In my experience it could be very flappy
for no particular reason we could discover. 1.1 is a pretty dusty version.
Upgrading into the 2.1 or later would be a good idea. If you have to upgrade in
place without down time, you will need to go through many upgrad
yeah that is most likely a bug, could you file a ticket?
On Tue, Mar 22, 2016 at 4:36 AM, Michael Fong <
michael.f...@ruckuswireless.com> wrote:
> Hi, all,
>
>
>
> We recently encountered a scenario under Cassandra 2.0 deployment.
> Cassandra detected a corrupted sstable, and when we attempt to s
Hello,
Suppose we change the racks on VMs on a running cluster. (We need to do this
while running on Azure, because sometimes when the VM gets moved its rack
changes).
In this situation, new writes will be laid out based on new rack info on
appropriate replicas. What happens for existing data
It would be nice for that message (and there is one more like it in the
driver) to say something more specific about how/where exactly to "report"
the situation. I mean, should users file Jira tickets for those two
scenarios or simply email to the Java (or other driver) email lists? The
message sho
I could be wrong on this since I've never actually attempted what you are
asking. Based on my understanding of how replica assignment is done, I
don't think that just changing the rack on an existing node is a good idea.
Changing racks for a node that already contains data would result in that
dat
Hi all,
I started running “stress tests” against my application which writes event data
to a local single-node Cassandra cluster (C* v2.2.4). After inserting a couple
thousand rows (all for the same partition key) I am starting to get warnings in
the C* log informing me about large numbers of t
On Wed, Mar 23, 2016 at 9:50 AM, Ralf Steppacher
wrote:
> How come I end up with that large a number of tombstones?
>
Are you inserting NULLs?
=Rob
On Wed, Mar 23, 2016 at 8:07 AM, Anubhav Kale
wrote:
> Suppose we change the racks on VMs on a running cluster. (We need to do
> this while running on Azure, because sometimes when the VM gets moved its
> rack changes).
>
> In this situation, new writes will be laid out based on new rack info on
Oh, and the query I ran was “select * from racktest.racktable where id=1”
From: Anubhav Kale [mailto:anubhav.k...@microsoft.com]
Sent: Wednesday, March 23, 2016 2:04 PM
To: user@cassandra.apache.org
Subject: RE: Rack aware question.
Thanks.
To test what happens when rack of a node changes in a r
Hi all,
I have a table that represents a train timetable and looks a bit like this:
CREATE TABLE routes (
start text,
end text,
validFrom timestamp,
validTo timestamp,
PRIMARY KEY (start, end, validFrom, validTo)
);
In this case validFrom is the date that the route becomes valid and validTo
is t
Actually, I believe you are seeing the behavior described in the ticket I
meant to link to, with the detailed exploration :
https://issues.apache.org/jira/browse/CASSANDRA-10238
=Rob
On Wed, Mar 23, 2016 at 2:06 PM, Anubhav Kale
wrote:
> Oh, and the query I ran was “select * from racktest.rac
Thanks for the pointer – appreciate it.
My test is on the latest trunk and slightly different.
I am not exactly sure if the behavior I see is expected (in which case, is the
recommendation to re-bootstrap just to avoid data movement?) or is the behavior
not expected and is a bug.
If we don’t w
> How come 127.0.0.1 is shown as an endpoint holding the ID when its token
range doesn’t contain it ? Does “nodetool ring” shows all token-ranges for
a node or just the primary range ? I am thinking its only primary. Can
someone confirm ?
The primary replica of id=1 is always 127.0.0.3. What chang
Thanks, Read repair is what I thought must be causing this, so I experimented
some more with setting read_repair_chance and dc_local_read_repair_chance on
the table to 0, and then 1.
Unfortunately, the results were somewhat random depending on which node I ran
the queries from. For example, whe
Flip the problem over. Instead of storing validTo and validFrom, simply
store a valid field and partition by (start, end). This may sound wasteful,
but disk is cheap:
CREATE TABLE routes (
start text,
end text,
valid timestamp,
PRIMARY KEY ((start, end), valid)
);
Now, you can execute something l
I ran into the following detail from :
https://wiki.apache.org/cassandra/ReadRepair
“If a lower ConsistencyLevel than ALL was specified, this is done in the
background after returning the data from the closest replica to the client;
otherwise, it is done before returning the data.”
I set consi
CL=ALL also means that you won't have HA (High Availability) - if even a
single node goes down, you're out of business. I mean, HA is the
fundamental reason for using the rack-aware policy - to assure that each
replica is on a separate power supply and network connection so that data
can be retriev
In addition to writing null values acting as tombstones, also INSERTing a
collection (or UPDATE where you set the collection rather than append to
it) are also operations which will create tombstones.
On Wed, Mar 23, 2016 at 12:09 PM Robert Coli wrote:
> On Wed, Mar 23, 2016 at 9:50 AM, Ralf Ste
What is the reason for the tombstone for a brand new insert? Do the fields
get written as a whole (both nulls and non-nulls?
I understand the rationale for tombstones for deletes and updates but it
does not make sense for an insert (I am trying to make sense of it). I
understand Cassandra writes t
Hi Henry,
Since new values are written without checking for previous values, the only
way to assure that a nulled column blocks a previously valid one is to
write a tombstone to occlude whatever value might have been present. I
believe there are some recent changes as to the handling of null value
Agreed with Jack.
I don't think there's ever a reason to use CL=ALL in an application in
production. I would only use it if I was debugging certain types of
consistency problems.
On Wed, Mar 23, 2016 at 4:56 PM Jack Krupansky
wrote:
> CL=ALL also means that you won't have HA (High Availability
The consistency ALL was only for my testing so there could be a logical
explanation to this. We use LOCAL_QUORUM in prod.
Original message
From: Jack Krupansky
Date: 3/23/2016 4:56 PM (GMT-08:00)
To: user@cassandra.apache.org
Subject: Re: Rack aware question.
CL=ALL also means
As a follow-up, I'm going to write a simple patch to expose the number of
flushed bytes from memtable to JMX, so that we can easily monitor it.
Here is the jira: https://issues.apache.org/jira/browse/CASSANDRA-11420
On Thu, Mar 10, 2016 at 12:55 PM, Jack Krupansky
wrote:
> The doc does say this
I haven't tried the new SASI indexer but it may help:
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md
On Wed, Mar 23, 2016 at 2:08 PM, Chris Martin wrote:
> Hi all,
>
> I have a table that represents a train timetable and looks a bit like this:
>
> CREATE TABLE routes (
> start text,
Hello there,
We are experimenting Counters in Cassandra 2.2.5. Our setup is that we have
6 nodes, across three different regions, and in each region, the
replication factor is 2. Basically, each nodes holds a full copy of the
data.
When are doing 30k/s counter increment/decrement per node, and at
Hi,
Thanks for your comment.
The Cassandra version is in 1.2.15, and we have also adjusted the
phi_convict_threshold to 12 in production. This setting works great in most of
the production cases, except for this particular one...
Also, adding more node is not a plausible option for now. :(
Aft
Yes. In this particular test there are four fields null., one of them in a UDT
instance.
I don’t set fields to null explicitly. I insert as JSON and those fields are
not in the particular message. But when I select the record the fields are
shown as null.
In real live almost all fields are opti
Hi,
I also have loads of tombstones while only inserting new rows without ever
deleting rows.
My rows contain null columns and also collections.
How can I avoid the creation of these tombstones?
Thanks for your help.
On 24 Mar,2016, at 02:08, Steve Robenalt
mailto:sroben...@highwire.org>> wr
Eric,
I am writing the whole record in a single INSERT INTO … JSON. I am not
"insert-updating" over an existing record nor do I run any UPDATE statements.
Ralf
> On 24.03.2016, at 01:47, Eric Stevens wrote:
>
> In addition to writing null values acting as tombstones, also INSERTing a
> coll
Same for me. Only inserts not replacing old records.
On 24 Mar,2016, at 07:42, Ralf Steppacher
mailto:ralf.viva...@gmail.com>> wrote:
Eric,
I am writing the whole record in a single INSERT INTO ... JSON. I am not
"insert-updating" over an existing record nor do I run any UPDATE statements.
R
34 matches
Mail list logo
